Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior

[J.P.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "J.P." <jp@neverwas.me>
>> Cc: emacs-erc@gnu.org, 62833@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.