Re: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior

[J.P.]

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

> So because detecting a user's intent isn't foolproof (not only with 1,
> but in general), we may want to extend the existing display options by
> offering some sort of universal escape hatch that affords more
> granular control.

I've attempted something along these lines with the attached patch. It
adds a new Custom type variant to all of ERC's buffer-display options.

> However, doing this alone won't cover the problem of communicating to
> each user-implemented instance of such an escape hatch the necessary
> specifics about the context in which Emacs' display machinery is being
> summoned. And I don't think switching away from the one-to-many
> arrangement we have now to a single option per context is doable because
> of the first problem of accurately detecting intent.
>
> So, as a compromise, I'm thinking we could extend all existing options
> to accommodate arbitrary "action" forms, which we'd then pass along to a
> new `display-buffer' call (in `erc-setup-buffer') before trusting and
> selecting whatever window it spits out.

Actually, instead of a `display-buffer' action alone, I went for a cons
of a `display-buffer'-compatible function, like `pop-to-buffer', and an
action argument, together.

> The point would be to supplement user-supplied "action alists" with
> extra contextual data to indicate things like the last slash command
> invoked. (Alternatively, we could relay the same info via global erc-*
> variables; doesn't matter to me.)

For this new variant I'm proposing, ERC calls the user's function with
the newly created buffer and a possibly augmented version of the action
that includes some well defined contextual clues in its alist. The
latter are enumerated in the doc strings of the various user options.

> However, even this wouldn't be a panacea. A user would still need to
> apply some extra elbow grease for things like your `my-connect-fun' or
> my DBus example, possibly by doing something like
>
>   (let ((erc-join-buffer
>          '(my-use-dedicated-frame (inhibit-same-window . t))))
>     (erc-tls :server ...))
>
> which doesn't seem all that painful. Although, at that point, why not
> just do
>
>   (display-buffer (let ((erc-join-buffer 'bury)) (erc-tls :server ...))
>                   '(my-use-dedicated-frame (inhibit-same-window . t)))
>
> which has always been possible and is no more complicated?

This would be preferable if we had more granular options that only
affected a single context, such as something exclusively for
non-interactive `erc-tls' invocations. However, as described above, our
existing options cover multiple contexts, so this approach falls short
in the end, which is a shame because the blanket changes I'm proposing
are somewhat invasive and add a nonzero amount of complexity.

0001-5.6-Allow-custom-display-buffer-actions-in-ERC.patch
Description: Text Data