GNU bug report logs - #67249
30.0.50; `same-frame` equivalent for `display-buffer-alist`

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67249 <at> debbugs.gnu.org
Subject: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
Date: Fri, 24 Nov 2023 10:05:20 +0100

> Here's a first candidate patch.
>
> I introduced a new function `display-buffer--pop-up-frame` so as to
> ignore `inhibit-new-frame` as a last resort.

Good idea.

> I also modified `display-buffer--other-frame-action` to use
> `display-buffer--pop-up-frame`, because it seems this is used only(?) in
> response to an explicit user request where the user does expect a new
> frame (like `C-x 5 b`) and so it seems to make sense to override even an
> `inhibit-new-frame` coming from `display-buffer-alist`.

>  (defvar display-buffer--other-frame-action
>    '((display-buffer-reuse-window
> -     display-buffer-pop-up-frame)
> +     display-buffer--pop-up-frame)
>      (reusable-frames . 0)
>      (inhibit-same-window . t))

This one is messy anyway but I never tried to tinker with it.  After
all, "0" means to probe any frame around _including_ the selected one.
It probably should call 'display-buffer-use-some-frame' and maybe also
'display-buffer-use-least-recent-window' with a suitable 'lru-frames'
entry.  Just that our FRAMES argument nomenclature does not allow to
exclude the selected frame from the list of frames to probe or return.

> +(defun display-buffer--pop-up-frame (buffer alist)
> +  "Like `display-buffer--pop-up-frame' but ignores `inhibit-new-frame'.

This seems to have an extra "-".

> PS: Am I the only one who finds it confusing how some functions
> named `display-buffer-<foo>` are meant to be used from the ACTIONs
> (i.e. from within `display-buffer`) while others are implemented on top
> of `display-buffer` (and thus should not be used within ACTIONS)?
> Could we try and find a clear naming convention to distinguish the two,
> or am I even more confused than I thought and several of those functions
> can be used either way?

Do you mean 'display-buffer-override-next-command' and
'display-buffer-record-window'?  As for the latter, the reason was that
applications might want to call this in their code for recording the
window used so it's not meant to be strictly window.el internal.  If you
mean something else, please give one or two examples of such confusing
functions.

martin

Previous Next

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