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

> I'm hoping this can serve as a unified "omnibug" for all the overlapping
> discourse scattered about regarding buffer-display options and the
> behavior they produce. The main focus will be those aspects impacting
> ERC 5.6 and how they integrate with the upstream display-buffer facility
> provided by window.el. In a sense, this is a spiritual successor to
>
>   bug#51753: ERC switches to channel buffer on reconnect

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.

For example, suppose (following a successful automatic reconnection) you
get back to chatting in a channel and receive a query from someone you
haven't spoken with yet. Instead of appealing to the rightful option, in
this case, `erc-auto-query', ERC instead displays the person's buffer
using `erc-reconnect-display'. The same goes for any JOIN initiated by a
/JOIN command issued in a channel buffer: `erc-join-buffer' should be
consulted but isn't. IMO, this constitutes an alarming enough problem to
warrant adding a warning to the option's doc string on the release
branch. It should say something to the effect of "bugged, do not use."

In the end, this all comes down to sheer sloppiness on my part. I had
intended to add the cancellation logic to `erc-process-input-line', but
for whatever reason (dimness of wit being the likeliest culprit),
neglected to do so and instead just stuck it in `erc-cmd-JOIN'.
(Shocking not shocking.) But even without that particular act of
bone-headedness, the problem would still be with us (albeit in a lesser
form). And while future request-tracking extensions will certainly help
for both autojoins and detecting unsolicited chathistory BATCHes, at
present, we simply can't tell when server-initiated playback ends (even
using heuristics, like comparing time stamps, because we don't even have
server-time).

IMO, as thing stand, the least bad (and only) "solution" is to use a
cancellation timer paired with a user option to designate a hard
timeout. See attached.

> 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.

> 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'.

> 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.