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

Corwin Brust <[email protected]> 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.