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

["J.P." <jp@neverwas.me>]

Hi Lars,

Lars Ingebrigtsen <larsi@gnus.org> writes:

> erc still pops up the buffer by default, I think?  I don't think it
> should do that, because it's both pretty annoying and a security
> issue -- you may suddenly be typing a password into an erc buffer.

Are you concerned about the behavior during initial connections as well
as automatic reconnections? Regardless, as you say, the default value of
`buffer' for `erc-join-buffer' (and `erc-reconnect-display') causes the
buffer in the selected window to be replaced with the
just-(re)initialized ERC buffer.

Also, depending on various factors, values other than `buffer' can
exhibit similar behavior. For example, in a dual-window split, a value
of `window-noselect' can result in a newly (re)joined channel replacing
the buffer in the selected window when the connection's server buffer is
showing in the other window. Plain `window' is much the same, but at
least there's somewhat of an expectation that the selected window's
buffer may change.

Really, the only safe option is `bury' (well, maybe also the proposed
frame stuff in Pankaj's patch, but only when an extra, ERC-specific
frame already exists, which we can't count on). That said, there's no
reason we'd have to stick with existing options/behavior when choosing a
new default. I guess it just comes down to what users want to happen.

If we're talking both `erc-join-buffer' and `erc-reconnect-display', one
idea would be to make `window-noselect' the default but change it to
mean the selected window is always left unmolested, no matter what. The
justification for the breaking change would be that the existing doc
string in

  (const :tag "Split window, don't select" window-noselect)

has always implied as much, namely that a window displaying the new
buffer will always be shown and never selected.

Although, if this only concerns `erc-reconnect-display', we could just
go with `bury' since (among the available options) that best minimizes
the disruption of a reestablished connection.

Hopefully folks have stronger opinions and/or better ideas. Thanks.