unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "J.P." <jp@neverwas.me>
To: 62833@debbugs.gnu.org
Cc: emacs-erc@gnu.org
Subject: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
Date: Mon, 08 May 2023 15:26:32 -0700	[thread overview]
Message-ID: <87jzxie9yf.fsf__43117.3074802913$1683584849$gmane$org@neverwas.me> (raw)
In-Reply-To: <87leiuy3cv.fsf@neverwas.me> (J. P.'s message of "Fri, 14 Apr 2023 06:56:16 -0700")

"J.P." <jp@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@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





  parent reply	other threads:[~2023-05-08 22:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87leiuy3cv.fsf@neverwas.me>
2023-04-21 14:03 ` bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior J.P.
     [not found] ` <87354tcoyk.fsf@neverwas.me>
2023-04-24 14:34   ` J.P.
2023-05-08 22:26 ` J.P. [this message]
     [not found] ` <87jzxie9yf.fsf@neverwas.me>
2023-05-10 21:43   ` Corwin Brust
     [not found]   ` <CAJf-WoTk1vT3gVSHdO7MRs6Rfn4PRcs8UWM=mw_NbzeCGHDfvQ@mail.gmail.com>
2023-05-13 14:03     ` J.P.
     [not found]     ` <87sfc08h19.fsf@neverwas.me>
2023-06-02 14:06       ` J.P.
2023-05-16 14:37 ` Phillip Susi
2023-06-04 14:52 ` J.P.
     [not found] ` <877csje0uz.fsf@neverwas.me>
2023-06-04 15:28   ` Eli Zaretskii
     [not found]   ` <837csj5jsh.fsf@gnu.org>
2023-06-04 21:36     ` J.P.
2023-06-09 13:50 ` J.P.
2023-06-22 13:48   ` J.P.
2023-07-08 14:19 ` J.P.
     [not found] ` <87r0pi32po.fsf@neverwas.me>
2023-07-14  2:11   ` J.P.
2023-04-14 13:56 J.P.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='87jzxie9yf.fsf__43117.3074802913$1683584849$gmane$org@neverwas.me' \
    --to=jp@neverwas.me \
    --cc=62833@debbugs.gnu.org \
    --cc=emacs-erc@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).