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

Previous Next

Package: emacs;

Reported by: "J.P." <jp <at> neverwas.me>

Date: Fri, 14 Apr 2023 13:57:01 UTC

Severity: normal

Tags: patch

Found in version 30.0.50

Done: "J.P." <jp <at> neverwas.me>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: 62833 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
Date: Fri, 09 Jun 2023 06:50:57 -0700
[Message part 1 (text/plain, inline)]
v2 (Custom function choice). Fix multiple misspellings of the variable
`erc-buffer-display'. Simplify defcustom type from cons to plain
function. Convert `displayed' frames variant to function item. Add
escape hatch for no-op when buffer matches `window-buffer'.

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

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

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 also added some
ready-made function items, though possibly only as placeholders.

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

I've described this briefly in the doc string for `erc-buffer-display'.

[0000-v1-v2.diff (text/x-patch, attachment)]

This bug report was last modified 1 year and 315 days ago.

Previous Next


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