"J.P." <jp@neverwas.me> writes:

> A troubling discovery has come to light regarding the option
> `erc-reconnect-display' (new in 5.5 and Emacs 29), which was the main
> product of bug#51753 before it pivoted to that frame-isolation feature.
> (This bug thread exists in part to move past that confusion.) The issue
> here concerns the time interval during which `erc-reconnect-display'
> takes precedence over its fellow buffer-display options, like
> `erc-join-buffer'. As things stand, this interval only ends for a
> session when `erc-cmd-JOIN' runs in the server buffer. Without that
> specific intervention, the option remains in effect for the remainder of
> the session.

This issue will be noted in the option's doc string in Emacs 29.

>> A more daring and arguably more meaningful move would be to repurpose
>> `erc-auto-query' (newly aliased to `erc-receive-query-display') as
>> something like a more general `erc-receive-display', which could cover
>> display handling for anything protocol driven (i.e.,
>> "non-interactive").
>
> Given the more pressing concerns noted above, I haven't yet devoted any
> thought to this but promise to eventually.

I'm pretty much convinced that there's no way to generalize this option
without wading back into bug#51753 territory. If a user already has it
customized to `buffer' or `window', the same risk of accidental sharing
exists, and rigging up warnings to intercept them on the first such
happening doesn't seem worth it. So, for this latest iteration, I've
abandoned this notion and have instead focused on making good on the
claims put forth by `erc-query-on-unjoined-chan-privmsg' and its doc
string decades ago.

Basically, this involves changing the current meaning of
`erc-auto-query' when nil to mean "defer to `erc-join-buffer'," which
brings it in line with all the other buffer-display options. An
obligatory compatibility flag for users to access the old behavior
rounds out the change. The basic wager we're making here is that the
chances of someone having `erc-join-buffer' set to 'buffer' or 'window'
while also having this option set to nil is negligible. The upside to be
gained is having `erc-query-on-unjoined-chan-privmsg', which I've
renamed `erc-ensure-target-buffer-on-privmsg', affect query buffers as
well as channels, which is a minor but solid UX win, IMO.

>> There's also the matter of assigning Custom groups for these options.
>> It'd be "nice" if we could tag these with multiple groups rather than
>> confine them to exclusive ownership. They're currently spread over
>> `erc-buffers', `erc-query', and `erc-display'. All seem to have valid
>> claims when you consider their respective constituencies.
>
> Actually, that's slightly untrue: the `erc-display' group doesn't
> include any buffer-display options. Regardless, for this iteration, I've
> stuck with the current group assignments, which are `erc-buffers' for
> all but `erc-receive-query-display', which lives in `erc-query'.

I've since learned (from Corwin) that options can indeed belong to
multiple groups, which is explained clearly enough in the manual. Armed
with this fact, I'm now thinking it would behoove us to assign
`erc-auto-query' and `erc-query-on-unjoined-chan-privmsg' to
`erc-buffers' but keep them in `erc-query' as well, for compatibility.

>> It's also been casually suggested that we might consider deferring to
>> `erc-setup-buffer' in areas not directly involved in message handling,
>> such as in erc-sidebar, to allow the options in question to influence
>> how buffers are displayed more generally. Not sure I have an opinion on
>> this quite yet, but if anyone else does, please share.
>
> This is also still to do.

And still.