v3 (Custom function choice). Change interface of function choice in
Custom `:type' spec to support full `display-buffer' action parameter.
Cancel second patch focusing on frames-related display styles (work to
continue in a separate bug).

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

> I've simplified this further. Instead of a cons of a `display-buffer'-
> compatible function and action, I think it's simpler to expect a
> function that takes as arguments the new buffer and a "context alist"
> (that can double as an "action alist"). This way, the user's code can
> inspect the context, assemble the action parameter appropriately, and
> dispatch `display-buffer' or similar as needed.

I've flip-flopped on this completely and have reverted back to favoring
the idea of having user implementations (and `function-item' offerings)
expect a full `display-buffer' action rather than just the alist portion
alone. As explained up thread, I originally figured it'd be easier on
users if we gave them just the alist to ponder rather than something
requiring destructuring and recomposing. But now I think it's cleaner to
sacrifice that minor convenience in favor of having folks mentally
associate these functions with `display-buffer', `pop-to-buffer', etc.,
since they roughly serve the same purpose (as opposed to the "action
functions" they consume).

Along with this U-turn, I think we ought to consider exporting the new
variable `erc--display-context'. I've left it internal, for now, but
making it public would allow folks with an existing collection of
`display-buffer' actions to write simple match predicates (for
`display-buffer-alist') that decide things based on calling context.

> I've also added some ready-made function items, though possibly only
> as placeholders.

Actually, looking back on

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

which led to a change that's been on HEAD for two months now

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e4c07dc

I've come to the belated realization that this feature is not all that
useful in and of itself. For whatever reason, I fixated on fulfilling
the requirements described in the bug without questioning whether that
alone would result in a satisfactory user experience. Indeed, after
actually trying out the feature from the perspective of someone wanting
to conduct all ERC-related business in a separate frame, merely offering
a display style oriented toward that end seems wholly insufficient.

For example, buffers spawned in other contexts, via related options,
such as `erc-receive-query-display', won't find their way to the correct
frame unless they've also been customized accordingly. Similarly, once a
buffer is correctly routed to a "dedicated" frame, it's unclear how the
user wants it displayed. I suppose we could affix existing options as
combined choices, like

  `erc-use-existing-frame-buffer'
  `erc-use-existing-frame-window'
  `erc-use-existing-frame-window-no-select'
  `erc-create-new-frame-buffer'
  ...

but that adds a lot of clutter and isn't great for maintenance. There's
also the issue of integrating with other modules, like `erc-track',
whose users likely want the mode line to only show changes for
associated buffers and C-SPC to limit its switching between those.

In sum, I think the basic idea of being able to marry new ERC buffers to
an ERC-managed frame is a good one, but it may be orthogonal to our
traditional idea of display styles. I'm now leaning toward exploring
something like a separate module to make the experience feel more
integrated and less bolted on. I therefore move that we revert the
change cited above in the meantime so people don't get used to it, and
then pursue a more comprehensive solution to frame-oriented
buffer-display styles in this (or some related) bug. Thanks.