Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame
"J.P." <[email protected]>
| Newsgroups | gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Lars, Lars Ingebrigtsen <[email protected]> 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.