Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
"J.P." <[email protected]>
| Newsgroups | gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
"J.P." <[email protected]> writes: > The main focus will be those aspects impacting ERC 5.6 and how they > integrate with the upstream display-buffer facility provided by > window.el. In a sense, this is a spiritual successor to > > bug#51753: ERC switches to channel buffer on reconnect Complaints continue to trickle in regarding the option `erc-join-buffer' and its new default of `bury'. To recap, bug#51753 led to changes [1] that altered how buffers are displayed in various contexts, most commonly: 1. (erc-tls :server ...) 2. M-x erc-tls RET 3. /JOIN #chan 4. /RECONNECT 5. automatically reconnect Basically, the attempted fix for 5 also affected the others, most of which are triggered by user interaction and therefore ought to have been exempt from any such nerfing (arguably). See, back before the change, a new or reassociated buffer would simply replace the one in the selected window. Now, in ERC 5.5 (Emacs 29), new buffers aren't displayed by default, and the only confirmation that anything's happened (after, say, invoking M-x erc-tls) is typically a blip in the mode-line. This lack of feedback has confused new users and irritated existing ones. Thus, I'm thinking we ought to consider changing the default in Emacs 29 to `window-noselect'. This is exactly what etc/ERC-NEWS currently recommends for personal setups anyway [2], and the behavior it triggers was newly redone in 5.5 to make good on its long advertised purpose, which is to show the new buffer in some other window via the `display-buffer' action (nil (inhibit-same-window . t)) which, AFAIK, never results in that window being selected. If true, then I believe `window-noselect' (at least, among the available choices) most closely approximates what will hopefully become an improved user experience in ERC 5.6. The main impediment I see to making such a change is that it would mean yet a third default value for this option in as many years (or four, if you count `bury' being forever baked into ERC 5.5 on ELPA). That's quite a bit of whiplash, and it speaks to our being overly equivocal (not untrue) if not wholly unprofessional (hopefully only possibly true). There's also the lesser matter of the current behavior having been somewhat suggested by an Emacs maintainer [3], which makes me less inclined to pursue a fix unless folks upset enough by the issue voice their concerns here on the tracker. Thanks. [1] commit 132d5cb0a3ec94afbb49772631861e00160ffffb Author: F. Jason Park <[email protected]> Date: Tue Sep 6 19:09:54 2022 -0700 Bury new ERC buffers by default * lisp/erc/erc.el (erc-join-buffer): Change default value to `bury'. [...] (Bug#51753) etc/ERC-NEWS | 14 +++++++-- lisp/erc/erc.el | 5 +-- test/lisp/erc/erc-scenarios-base-reconnect.el | 45 ++++++++++++++------------- 3 files changed, 37 insertions(+), 27 deletions(-) [2] ** Changes to display options for new ERC buffers. The default value for the option 'erc-join-buffer', which determines how new buffers are displayed, has been changed to 'bury' for security reasons. Although the old value of 'buffer' is still accessible, along with its original behavior, users wanting a safer alternative can now opt for an improved 'window-noselect' instead. It still offers the same pronounced visual cue when connecting and joining but now avoids any hijacking of the active window as well. [3] https://lists.gnu.org/archive/html/emacs-erc/2022-09/msg00006.html