GNU bug report logs - #62833
30.0.50; ERC 5.6: Rethink buffer-display options and behavior

Previous Next

Full log

View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: Corwin Brust <corwin <at> bru.st>, emacs-erc <at> gnu.org
Subject: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
Date: Fri, 02 Jun 2023 07:06:03 -0700

[Message part 1 (text/plain, inline)]

"J.P." <jp <at> 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 (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.