GNU bug report logs - #62833
30.0.50; ERC 5.6: Rethink buffer-display options and behavior

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62833 in the body.
You can then email your comments to 62833 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
Date: Fri, 14 Apr 2023 06:56:16 -0700

[Message part 1 (text/plain, inline)]

Tags: patch

Hi,

I'm hoping this can serve as a unified "omnibug" for all the overlapping
discourse scattered about regarding buffer-display options and the
behavior they produce. 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

and will inherit the outstanding display-related portions of

  bug#60428: 30.0.50; ERC >5.5: Make M-x erc a more welcoming entry point

the most recent being this proposal:

> This bug's original patch set tried to walk back an austere aspect of
> bug#51753's changes that lumped interactive buffer creation in with
> protocol driven creation. It mainly did so by introducing a new option,
> `erc-interactive-display', that reinstated direct window-buffer
> replacement when running M-x erc. However, as pointed out by Corwin on
> Libera, this did not account for interactive /JOINs.
>
> The attached patch aims to address this oversight as well as simplify
> the display-options picture a bit further by consolidating the roles of
> `erc-interactive-display' and `erc-query-display'. The thinking is that
> both options cover the same basic ground involving buffers created as a
> consequence of issuing slash commands. This patch also adds an interface
> for other such commands to use for detecting when they're being called
> from the command line.

Despite this, I'm still rather unsure about merging our ancient display
options. Aliasing `erc-interactive-display' to `erc-query-display' seems
sane because the latter only appears once, in an interactive command. A
more daring and arguably more meaningful move would be to repurpose
`erc-auto-query' (newly aliased to `erc-receive-query-display') as
something like a more general `erc-receive-display', which could cover
display handling for anything protocol driven (i.e., "non-interactive").
Among the reasons to abstain might be

  1. it would necessarily involve redefining the meaning of the option's
     nil value to mean "fall back to erc-join-buffer" instead of "print
     to the server buffer instead," which has no available alternative

  2. it invites an initial security risk (reminiscent of bug#51753)
     or at least a service interruption

For the first point, redefining the nil value is probably justified in
theory because all other values only concern themselves with where a
buffer is displayed, not where messages are routed for printing or
whether buffers are even created, which is the province of dedicated
switches (see note below re `erc-query-on-unjoined-chan-privmsg'). So I
guess this really comes down to whether providing an alternative
companion option and noting it in the doc string is an acceptable trade
off. Point two is more challenging but could perhaps be addressed by a
one-off warning requiring a click-through, before which
`erc-join-buffer' (now `erc-buffer-display') would remain in effect.

There's also the matter of assigning Custom groups for these options.
It'd be "nice" if we could tag these with multiple groups rather than
confine them to exclusive ownership. They're currently spread over
`erc-buffers', `erc-query', and `erc-display'. All seem to have valid
claims when you consider their respective constituencies.

It's also been casually suggested that we might consider deferring to
`erc-setup-buffer' in areas not directly involved in message handling,
such as in erc-sidebar, to allow the options in question to influence
how buffers are displayed more generally. Not sure I have an opinion on
this quite yet, but if anyone else does, please share.

Lastly, I've tacked on another patch that's somewhat related in the
buffer-creation (but not so much -display) sense. It concerns the
restoration of the option `erc-query-on-unjoined-chan-privmsg', which
was orphaned in 5.5 (by me) both out of ignorance and an abundance of
caution.

Thanks.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.17.6) of 2023-04-12 built on localhost
Repository revision: 861cf3a5c9d2081d811dcfc2c5ce5357f3dc44d4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3'
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils erc auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map format-spec
cl-loaddefs cl-lib erc-backend erc-networks byte-opt gv bytecomp
byte-compile erc-common erc-compat erc-loaddefs rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 63110 9012)
 (symbols 48 8532 0)
 (strings 32 23158 1921)
 (string-bytes 1 669049)
 (vectors 16 14968)
 (vector-slots 8 206726 6655)
 (floats 8 24 39)
 (intervals 56 231 0)
 (buffers 976 10))

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-5.6-Revive-option-erc-query-on-unjoined-chan-privmsg.patch (text/x-patch, attachment)]

[0002-5.6-Extend-erc-interactive-display-to-cover-JOINs.patch (text/x-patch, attachment)]

Message #8 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Fri, 21 Apr 2023 07:03:15 -0700

[Message part 1 (text/plain, inline)]

"J.P." <jp <at> neverwas.me> writes:

> I'm hoping this can serve as a unified "omnibug" for all the overlapping
> discourse scattered about regarding buffer-display options and the
> behavior they produce. 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

A troubling discovery has come to light regarding the option
`erc-reconnect-display' (new in 5.5 and Emacs 29), which was the main
product of bug#51753 before it pivoted to that frame-isolation feature.
(This bug thread exists in part to move past that confusion.) The issue
here concerns the time interval during which `erc-reconnect-display'
takes precedence over its fellow buffer-display options, like
`erc-join-buffer'. As things stand, this interval only ends for a
session when `erc-cmd-JOIN' runs in the server buffer. Without that
specific intervention, the option remains in effect for the remainder of
the session.

For example, suppose (following a successful automatic reconnection) you
get back to chatting in a channel and receive a query from someone you
haven't spoken with yet. Instead of appealing to the rightful option, in
this case, `erc-auto-query', ERC instead displays the person's buffer
using `erc-reconnect-display'. The same goes for any JOIN initiated by a
/JOIN command issued in a channel buffer: `erc-join-buffer' should be
consulted but isn't. IMO, this constitutes an alarming enough problem to
warrant adding a warning to the option's doc string on the release
branch. It should say something to the effect of "bugged, do not use."

In the end, this all comes down to sheer sloppiness on my part. I had
intended to add the cancellation logic to `erc-process-input-line', but
for whatever reason (dimness of wit being the likeliest culprit),
neglected to do so and instead just stuck it in `erc-cmd-JOIN'.
(Shocking not shocking.) But even without that particular act of
bone-headedness, the problem would still be with us (albeit in a lesser
form). And while future request-tracking extensions will certainly help
for both autojoins and detecting unsolicited chathistory BATCHes, at
present, we simply can't tell when server-initiated playback ends (even
using heuristics, like comparing time stamps, because we don't even have
server-time).

IMO, as thing stand, the least bad (and only) "solution" is to use a
cancellation timer paired with a user option to designate a hard
timeout. See attached.

> A more daring and arguably more meaningful move would be to repurpose
> `erc-auto-query' (newly aliased to `erc-receive-query-display') as
> something like a more general `erc-receive-display', which could cover
> display handling for anything protocol driven (i.e.,
> "non-interactive").

Given the more pressing concerns noted above, I haven't yet devoted any
thought to this but promise to eventually.

> There's also the matter of assigning Custom groups for these options.
> It'd be "nice" if we could tag these with multiple groups rather than
> confine them to exclusive ownership. They're currently spread over
> `erc-buffers', `erc-query', and `erc-display'. All seem to have valid
> claims when you consider their respective constituencies.

Actually, that's slightly untrue: the `erc-display' group doesn't
include any buffer-display options. Regardless, for this iteration, I've
stuck with the current group assignments, which are `erc-buffers' for
all but `erc-receive-query-display', which lives in `erc-query'.

> It's also been casually suggested that we might consider deferring to
> `erc-setup-buffer' in areas not directly involved in message handling,
> such as in erc-sidebar, to allow the options in question to influence
> how buffers are displayed more generally. Not sure I have an opinion on
> this quite yet, but if anyone else does, please share.

This is also still to do.

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-5.6-Revive-option-erc-query-on-unjoined-chan-privmsg.patch (text/x-patch, attachment)]

[0002-5.6-Move-ERC-s-buffer-display-tests-to-separate-file.patch (text/x-patch, attachment)]

[0003-5.6-Extend-erc-interactive-display-to-cover-JOINs.patch (text/x-patch, attachment)]

[0004-5.6-Ignore-erc-reconnect-display-after-a-timeout.patch (text/x-patch, attachment)]

Message #11 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Mon, 24 Apr 2023 07:34:53 -0700

[Message part 1 (text/plain, inline)]

"J.P." <jp <at> neverwas.me> writes:

> A troubling discovery has come to light regarding the option
> `erc-reconnect-display' (new in 5.5 and Emacs 29), which was the main
> product of bug#51753 before it pivoted to that frame-isolation feature.
> (This bug thread exists in part to move past that confusion.) The issue
> here concerns the time interval during which `erc-reconnect-display'
> takes precedence over its fellow buffer-display options, like
> `erc-join-buffer'. As things stand, this interval only ends for a
> session when `erc-cmd-JOIN' runs in the server buffer. Without that
> specific intervention, the option remains in effect for the remainder of
> the session.

This issue will be noted in the option's doc string in Emacs 29.

>> A more daring and arguably more meaningful move would be to repurpose
>> `erc-auto-query' (newly aliased to `erc-receive-query-display') as
>> something like a more general `erc-receive-display', which could cover
>> display handling for anything protocol driven (i.e.,
>> "non-interactive").
>
> Given the more pressing concerns noted above, I haven't yet devoted any
> thought to this but promise to eventually.

I'm pretty much convinced that there's no way to generalize this option
without wading back into bug#51753 territory. If a user already has it
customized to `buffer' or `window', the same risk of accidental sharing
exists, and rigging up warnings to intercept them on the first such
happening doesn't seem worth it. So, for this latest iteration, I've
abandoned this notion and have instead focused on making good on the
claims put forth by `erc-query-on-unjoined-chan-privmsg' and its doc
string decades ago.

Basically, this involves changing the current meaning of
`erc-auto-query' when nil to mean "defer to `erc-join-buffer'," which
brings it in line with all the other buffer-display options. An
obligatory compatibility flag for users to access the old behavior
rounds out the change. The basic wager we're making here is that the
chances of someone having `erc-join-buffer' set to 'buffer' or 'window'
while also having this option set to nil is negligible. The upside to be
gained is having `erc-query-on-unjoined-chan-privmsg', which I've
renamed `erc-ensure-target-buffer-on-privmsg', affect query buffers as
well as channels, which is a minor but solid UX win, IMO.

>> There's also the matter of assigning Custom groups for these options.
>> It'd be "nice" if we could tag these with multiple groups rather than
>> confine them to exclusive ownership. They're currently spread over
>> `erc-buffers', `erc-query', and `erc-display'. All seem to have valid
>> claims when you consider their respective constituencies.
>
> Actually, that's slightly untrue: the `erc-display' group doesn't
> include any buffer-display options. Regardless, for this iteration, I've
> stuck with the current group assignments, which are `erc-buffers' for
> all but `erc-receive-query-display', which lives in `erc-query'.

I've since learned (from Corwin) that options can indeed belong to
multiple groups, which is explained clearly enough in the manual. Armed
with this fact, I'm now thinking it would behoove us to assign
`erc-auto-query' and `erc-query-on-unjoined-chan-privmsg' to
`erc-buffers' but keep them in `erc-query' as well, for compatibility.

>> It's also been casually suggested that we might consider deferring to
>> `erc-setup-buffer' in areas not directly involved in message handling,
>> such as in erc-sidebar, to allow the options in question to influence
>> how buffers are displayed more generally. Not sure I have an opinion on
>> this quite yet, but if anyone else does, please share.
>
> This is also still to do.

And still.

[0000-v3-v4.diff (text/x-patch, attachment)]

[0001-5.6-Revive-option-erc-query-on-unjoined-chan-privmsg.patch (text/x-patch, attachment)]

[0002-5.6-Move-ERC-s-buffer-display-tests-to-separate-file.patch (text/x-patch, attachment)]

[0003-5.6-Extend-erc-interactive-display-to-cover-JOINs.patch (text/x-patch, attachment)]

[0004-5.6-Ignore-erc-reconnect-display-after-a-timeout.patch (text/x-patch, attachment)]

Message #14 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Mon, 08 May 2023 15:26:32 -0700

"J.P." <jp <at> neverwas.me> 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 <jp <at> neverwas.me>
    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

Message #17 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: "J.P." <jp <at> neverwas.me>
Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
Subject: Re: bug#62833: 30.0.50;
 ERC 5.6: Rethink buffer-display options and behavior
Date: Wed, 10 May 2023 16:43:42 -0500

Thank you, JP.

On Mon, May 8, 2023 at 5:26 PM J.P. <jp <at> neverwas.me> wrote:
>
> "J.P." <jp <at> neverwas.me> 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]

Please add me to the list of people who didn't much care for the new default.

> 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

FWIW, I connect automatically on startup using a desktop shortcut
running a command something like:
  emacs -f my-erc-init.el -eval "(my-connect-fun)"

>
> 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'

FWIW, I'd prefer that to the present situation.  My sense from chatter
on IRC is that this probably matches others expectations also but
perhaps someone who prefers the new and now current default setting of
bury will weigh in here and dispell my confirmation bias ;)

> 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.

I don't see an issue with multiple changes to a default within a short
time, either within an ERC version or in several consecutive ones.
Changing it each *Emacs* version seems more problematic, but I think
that's not an issue (so far) in this case.

So I think now is a very good time to make the change, and I'd like to
see it happen.

I hope other ERC users who feel strongly about this will weigh in.

>
> Thanks.
>
>
> [1] commit 132d5cb0a3ec94afbb49772631861e00160ffffb
>     Author: F. Jason Park <jp <at> neverwas.me>
>     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
>

Really appreciate your work on this JP

Message #20 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Corwin Brust <corwin <at> bru.st>
Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Sat, 13 May 2023 07:03:46 -0700

Corwin Brust <corwin <at> bru.st> writes:

>> 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
>
> FWIW, I connect automatically on startup using a desktop shortcut
> running a command something like:
>   emacs -f my-erc-init.el -eval "(my-connect-fun)"

I guess I could have tried grouping these into user-initiated and non-,
but it seems to me the first item, `erc-tls', can go either way. While
your example, which presumably calls `erc-tls' at some point, clearly
falls into the user-initiated camp, the same might not be said, for
example, of running `erc-tls' whenever Emacs receives a specific message
over DBus. So because detecting a user's intent isn't foolproof (not
only with 1, but in general), we may want to extend the existing display
options by offering some sort of universal escape hatch that affords
more granular control.

However, doing this alone won't cover the problem of communicating to
each user-implemented instance of such an escape hatch the necessary
specifics about the context in which Emacs' display machinery is being
summoned. And I don't think switching away from the one-to-many
arrangement we have now to a single option per context is doable because
of the first problem of accurately detecting intent.

So, as a compromise, I'm thinking we could extend all existing options
to accommodate arbitrary "action" forms, which we'd then pass along to a
new `display-buffer' call (in `erc-setup-buffer') before trusting and
selecting whatever window it spits out. The point would be to supplement
user-supplied "action alists" with extra contextual data to indicate
things like the last slash command invoked. (Alternatively, we could
relay the same info via global erc-* variables; doesn't matter to me.)
However, even this wouldn't be a panacea. A user would still need to
apply some extra elbow grease for things like your `my-connect-fun' or
my DBus example, possibly by doing something like

  (let ((erc-join-buffer
         '(my-use-dedicated-frame (inhibit-same-window . t))))
    (erc-tls :server ...))

which doesn't seem all that painful. Although, at that point, why not
just do

  (display-buffer (let ((erc-join-buffer 'bury)) (erc-tls :server ...))
                  '(my-use-dedicated-frame (inhibit-same-window . t)))

which has always been possible and is no more complicated?

>> 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'
>
> FWIW, I'd prefer that to the present situation.  My sense from chatter
> on IRC is that this probably matches others expectations also but
> perhaps someone who prefers the new and now current default setting of
> bury will weigh in here and dispell my confirmation bias ;)

That's my sense as well.

>> 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.
>
> I don't see an issue with multiple changes to a default within a short
> time, either within an ERC version or in several consecutive ones.
> Changing it each *Emacs* version seems more problematic, but I think
> that's not an issue (so far) in this case.

Just to recap, here are the default values of `erc-join-buffer' (now
also aliased to `erc-buffer-display' on HEAD):

  5.4        - buffer
  5.5        - bury
  5.5.1.29.1 - window-noselect (proposed)
  5.6        - bury (repurposed as a catch-all)

In the last one, "catch-all" not only means it's overridden by other
options, which has always been the case, but that contexts formerly
within its domain, like M-x erc and "/JOIN", are now determined
elsewhere, such as by `erc-interactive-display' (currently `window').
(BTW, "/RECONNECT" currently isn't covered by the latter, but that could
change if folks want.)

> So I think now is a very good time to make the change, and I'd like to
> see it happen.
>
> I hope other ERC users who feel strongly about this will weigh in.

I suppose it couldn't hurt to get a patch going for "5.5.1.29.1", just
to have something on standby.

> Really appreciate your work on this JP

Very kind, thanks.

Message #23 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <phill <at> thesusis.net>
To: 62833 <at> debbugs.gnu.org
Subject: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
Date: Tue, 16 May 2023 10:37:44 -0400

+1 from me.

This behavior change was highly surprising.  I thought ERC was just
broken until I checked the buffer list and saw it had just decided to
open in the background.

Message #26 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: Corwin Brust <corwin <at> bru.st>, emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Fri, 02 Jun 2023 07:06:03 -0700

[Message part 1 (text/plain, inline)]

"J.P." <jp <at> neverwas.me> writes:

> So because detecting a user's intent isn't foolproof (not only with 1,
> but in general), we may want to extend the existing display options by
> offering some sort of universal escape hatch that affords more
> granular control.

I've attempted something along these lines with the attached patch. It
adds a new Custom type variant to all of ERC's buffer-display options.

> However, doing this alone won't cover the problem of communicating to
> each user-implemented instance of such an escape hatch the necessary
> specifics about the context in which Emacs' display machinery is being
> summoned. And I don't think switching away from the one-to-many
> arrangement we have now to a single option per context is doable because
> of the first problem of accurately detecting intent.
>
> So, as a compromise, I'm thinking we could extend all existing options
> to accommodate arbitrary "action" forms, which we'd then pass along to a
> new `display-buffer' call (in `erc-setup-buffer') before trusting and
> selecting whatever window it spits out.

Actually, instead of a `display-buffer' action alone, I went for a cons
of a `display-buffer'-compatible function, like `pop-to-buffer', and an
action argument, together.

> The point would be to supplement user-supplied "action alists" with
> extra contextual data to indicate things like the last slash command
> invoked. (Alternatively, we could relay the same info via global erc-*
> variables; doesn't matter to me.)

For this new variant I'm proposing, ERC calls the user's function with
the newly created buffer and a possibly augmented version of the action
that includes some well defined contextual clues in its alist. The
latter are enumerated in the doc strings of the various user options.

> However, even this wouldn't be a panacea. A user would still need to
> apply some extra elbow grease for things like your `my-connect-fun' or
> my DBus example, possibly by doing something like
>
>   (let ((erc-join-buffer
>          '(my-use-dedicated-frame (inhibit-same-window . t))))
>     (erc-tls :server ...))
>
> which doesn't seem all that painful. Although, at that point, why not
> just do
>
>   (display-buffer (let ((erc-join-buffer 'bury)) (erc-tls :server ...))
>                   '(my-use-dedicated-frame (inhibit-same-window . t)))
>
> which has always been possible and is no more complicated?

This would be preferable if we had more granular options that only
affected a single context, such as something exclusively for
non-interactive `erc-tls' invocations. However, as described above, our
existing options cover multiple contexts, so this approach falls short
in the end, which is a shame because the blanket changes I'm proposing
are somewhat invasive and add a nonzero amount of complexity.

[0001-5.6-Allow-custom-display-buffer-actions-in-ERC.patch (text/x-patch, attachment)]

Message #29 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Sun, 04 Jun 2023 07:52:20 -0700

[Message part 1 (text/plain, inline)]

Hi Eli,

This is regarding a small prospective change to ERC on Emacs 29 that's
been discussed here and there over the past few months [1]. Basically,
ERC has long defaulted to displaying new buffers in the currently
selected window, with the symbol `buffer' representing this display
style in various user options. Because new buffers are often created as
a result of server-initiated messages or feature-driven automated
mechanisms, like "autojoin", they can suddenly appear unceremoniously
and steal keyboard input. For this reason, `buffer' was deemed a
nuisance (if not a hazard), and the default was changed to a no-op in
ERC 5.5 [2].

However, since then, a faint but steady murmur of discontent has been
thrumming among mostly new and casual users, who've described ERC as
being "broken" in this regard because it provides little to no obvious
feedback following certain fundamental user actions, like connecting to
a server or joining a channel. IOW, users can't tell whether ERC is
responding to a command they've just issued, despite subtle cues, like
activity in the echo area and the mode line.

The solution to all this isn't straightforward, and we're making headway
on it for ERC 5.6. In the meantime, I'm wondering if we might consider
appeasing these disgruntled users somehow. Normally, I'd prefer just
reverting back to `buffer', but because much has been made about its
potential for causing mayhem via unintended sharing, I'm thinking we
might change the default in Emacs 29 to `window-noselect'. This value
tells ERC to show new buffers in a sibling window of the same vertical
combination. Such a change would be accompanied by a bump in the patch
component of our already 29-specific ERC version, bringing us from
5.5.0.29.1 to 5.5.1.29.1. I believe the attached patch does what I've
described.

Thanks,
J.P.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60428#31
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62833#17
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62833#23

[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51753#71

[0001-Add-erc-join-buffer-hotfix-in-new-version-5.5.1.29.1.patch (text/x-patch, attachment)]

Message #32 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "J.P." <jp <at> neverwas.me>
Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Sun, 04 Jun 2023 18:28:14 +0300

> From: "J.P." <jp <at> neverwas.me>
> Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
> Date: Sun, 04 Jun 2023 07:52:20 -0700
> 
> The solution to all this isn't straightforward, and we're making headway
> on it for ERC 5.6. In the meantime, I'm wondering if we might consider
> appeasing these disgruntled users somehow. Normally, I'd prefer just
> reverting back to `buffer', but because much has been made about its
> potential for causing mayhem via unintended sharing, I'm thinking we
> might change the default in Emacs 29 to `window-noselect'. This value
> tells ERC to show new buffers in a sibling window of the same vertical
> combination.

I don't use ERC, but how does it make sense to change the default so
close to a release?  I could understand reverting back to 'buffer',
which was used for a long time, but switching to a new default that
had no real testing period?  Are you absolutely sure this is a good
idea?  And on top of that, change it only for Emacs 29?

Message #35 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Sun, 04 Jun 2023 14:36:21 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "J.P." <jp <at> neverwas.me>
>> Cc: emacs-erc <at> gnu.org, 62833 <at> debbugs.gnu.org
>> Date: Sun, 04 Jun 2023 07:52:20 -0700
>> 
>> The solution to all this isn't straightforward, and we're making headway
>> on it for ERC 5.6. In the meantime, I'm wondering if we might consider
>> appeasing these disgruntled users somehow. Normally, I'd prefer just
>> reverting back to `buffer', but because much has been made about its
>> potential for causing mayhem via unintended sharing, I'm thinking we
>> might change the default in Emacs 29 to `window-noselect'. This value
>> tells ERC to show new buffers in a sibling window of the same vertical
>> combination.
>
> I don't use ERC, but how does it make sense to change the default so
> close to a release?

Doing this is not without risk, but if it's any consolation, it's
perhaps somewhat less fraught given that `window-noselect' has always
been the default for `erc-auto-query', whose value is bound to
`erc-join-buffer' when displaying direct private messages. Since these
are not uncommon, we at least know that in one specific context, this
display style has stood the test of time.

> I could understand reverting back to 'buffer', which was used for a
> long time, but switching to a new default that had no real testing
> period? Are you absolutely sure this is a good idea?

There are no good ideas here, and I'd say it's a wash between `buffer'
and `window-noselect' depending on whose priorities we're intent on
favoring. I'd feel better about going back to `buffer' if those who
advocated for dropping it in bug#51753 would be willing to concede that
user feedback has proven that solution insufficient.

> And on top of that, change it only for Emacs 29?

Yes only for Emacs 29. This problem doesn't exist in Emacs 30.

In the end, this issue probably isn't worth much more of anyone's time.
Come late July-ish, we'll hopefully have ERC 5.6 out the door and can
just redirect folks there. And until then, this brief email exchange
should prove useful enough in fending off any related FUD on IRC.

To others listening in, I can only reiterate that this, along with other
20yr old UX bugs addressed in ERC 5.6 have been a major distraction that
I should have, in retrospect, had the wherewithal to ignore in lieu of
focusing on ERC's more existential problems, which I've been belaboring
for the better part of three years. The most pressing of these is, of
course, the adoption of essential protocol extensions, without which ERC
will not long survive.

Message #38 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Fri, 09 Jun 2023 06:50:57 -0700

[Message part 1 (text/plain, inline)]

v2 (Custom function choice). Fix multiple misspellings of the variable
`erc-buffer-display'. Simplify defcustom type from cons to plain
function. Convert `displayed' frames variant to function item. Add
escape hatch for no-op when buffer matches `window-buffer'.

"J.P." <jp <at> neverwas.me> writes:

> Actually, instead of a `display-buffer' action alone, I went for a cons
> of a `display-buffer'-compatible function, like `pop-to-buffer', and an
> action argument, together.
>
> [...]
>
> For this new variant I'm proposing, ERC calls the user's function with
> the newly created buffer and a possibly augmented version of the action
> that includes some well defined contextual clues in its alist. The
> latter are enumerated in the doc strings of the various user options.

I've simplified this further. Instead of a cons of a `display-buffer'-
compatible function and action, I think it's simpler to expect a
function that takes as arguments the new buffer and a "context alist"
(that can double as an "action alist"). This way, the user's code can
inspect the context, assemble the action parameter appropriately, and
dispatch `display-buffer' or similar as needed. I've also added some
ready-made function items, though possibly only as placeholders.

>> Although, at that point, why not just do
>>
>>   (display-buffer (let ((erc-join-buffer 'bury)) (erc-tls :server ...))
>>                   '(my-use-dedicated-frame (inhibit-same-window . t)))
>>
>> which has always been possible and is no more complicated?
>
> This would be preferable if we had more granular options that only
> affected a single context, such as something exclusively for
> non-interactive `erc-tls' invocations.

I've described this briefly in the doc string for `erc-buffer-display'.

[0000-v1-v2.diff (text/x-patch, attachment)]

Message #41 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Thu, 22 Jun 2023 06:48:40 -0700

[Message part 1 (text/plain, inline)]

v3 (Custom function choice). Change interface of function choice in
Custom `:type' spec to support full `display-buffer' action parameter.
Cancel second patch focusing on frames-related display styles (work to
continue in a separate bug).

"J.P." <jp <at> neverwas.me> writes:

> I've simplified this further. Instead of a cons of a `display-buffer'-
> compatible function and action, I think it's simpler to expect a
> function that takes as arguments the new buffer and a "context alist"
> (that can double as an "action alist"). This way, the user's code can
> inspect the context, assemble the action parameter appropriately, and
> dispatch `display-buffer' or similar as needed.

I've flip-flopped on this completely and have reverted back to favoring
the idea of having user implementations (and `function-item' offerings)
expect a full `display-buffer' action rather than just the alist portion
alone. As explained up thread, I originally figured it'd be easier on
users if we gave them just the alist to ponder rather than something
requiring destructuring and recomposing. But now I think it's cleaner to
sacrifice that minor convenience in favor of having folks mentally
associate these functions with `display-buffer', `pop-to-buffer', etc.,
since they roughly serve the same purpose (as opposed to the "action
functions" they consume).

Along with this U-turn, I think we ought to consider exporting the new
variable `erc--display-context'. I've left it internal, for now, but
making it public would allow folks with an existing collection of
`display-buffer' actions to write simple match predicates (for
`display-buffer-alist') that decide things based on calling context.

> I've also added some ready-made function items, though possibly only
> as placeholders.

Actually, looking back on

  bug#55540: 29.0.50; ERC launches autojoin-channels in current frame

which led to a change that's been on HEAD for two months now

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e4c07dc

I've come to the belated realization that this feature is not all that
useful in and of itself. For whatever reason, I fixated on fulfilling
the requirements described in the bug without questioning whether that
alone would result in a satisfactory user experience. Indeed, after
actually trying out the feature from the perspective of someone wanting
to conduct all ERC-related business in a separate frame, merely offering
a display style oriented toward that end seems wholly insufficient.

For example, buffers spawned in other contexts, via related options,
such as `erc-receive-query-display', won't find their way to the correct
frame unless they've also been customized accordingly. Similarly, once a
buffer is correctly routed to a "dedicated" frame, it's unclear how the
user wants it displayed. I suppose we could affix existing options as
combined choices, like

  `erc-use-existing-frame-buffer'
  `erc-use-existing-frame-window'
  `erc-use-existing-frame-window-no-select'
  `erc-create-new-frame-buffer'
  ...

but that adds a lot of clutter and isn't great for maintenance. There's
also the issue of integrating with other modules, like `erc-track',
whose users likely want the mode line to only show changes for
associated buffers and C-SPC to limit its switching between those.

In sum, I think the basic idea of being able to marry new ERC buffers to
an ERC-managed frame is a good one, but it may be orthogonal to our
traditional idea of display styles. I'm now leaning toward exploring
something like a separate module to make the experience feel more
integrated and less bolted on. I therefore move that we revert the
change cited above in the meantime so people don't get used to it, and
then pursue a more comprehensive solution to frame-oriented
buffer-display styles in this (or some related) bug. Thanks.

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-Revert-Allow-erc-reuse-frames-to-favor-connections.patch (text/x-patch, attachment)]

[0002-5.6-Allow-custom-display-buffer-actions-in-ERC.patch (text/x-patch, attachment)]

Message #44 received at 62833 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Sat, 08 Jul 2023 07:19:47 -0700

[Message part 1 (text/plain, inline)]

v4. Add new section to manual. Alias `erc-reconnect-display' to
`erc-auto-reconnect-display'. Add new contexts for `autojoin' module and
manual /RECONNECT invocations. Add option to force displaying of server
buffers when reconnecting.

[0000-v3-v4.diff (text/x-patch, attachment)]

[0001-5.6-Allow-custom-display-buffer-actions-in-ERC.patch (text/x-patch, attachment)]

Message #49 received at 62833-done <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 62833-done <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and
 behavior
Date: Thu, 13 Jul 2023 19:11:44 -0700

"J.P." <jp <at> neverwas.me> writes:

> v4. Add new section to manual. Alias `erc-reconnect-display' to
> `erc-auto-reconnect-display'. Add new contexts for `autojoin' module and
> manual /RECONNECT invocations. Add option to force displaying of server
> buffers when reconnecting.

I've installed a version of this as

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b354b3a5

Because of the sweeping scope of these changes, it's quite likely we'll
have to reopen this at some point.

Thanks and closing (for now).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.