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

Previous Next

Full log

Message #14 received at 67249 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67249 <at> debbugs.gnu.org
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
 `display-buffer-alist`
Date: Sun, 19 Nov 2023 11:35:06 +0100

>>> As `special-display-buffer-names` and friends are nearing the 10 years
>>> of being declared obsolete, I noticed that I can't find any replacement
>>> for the `same-frame` parameter in `display-buffer-alist`.
>> IIRC 'same-frame' had no clear semantics.
>
> In `special-display-*`?

All 'same-frame' did was to inhibit calling 'special-display-function'
via

	 (let* ((pop-up-frames nil) (pop-up-windows t)
		special-display-regexps special-display-buffer-names
		(window (display-buffer buffer)))

That never precluded using a window on another frame, contradicting the
very meaning of "same frame" and was always documented as

  "Otherwise, if they include (same-frame . t), the buffer is displayed
   in a new window in the currently selected frame."

which failed to say what happens if no new window could be created on
the selected frame.  So historically 'same-frame' was always tied to
'special-display-*' and had no effect when that was uncustomized.

> Are you referring to whether it's OK to (re)use a window on another
> frame if it shows the buffer already?

(Re)use any window on another frame.

> Other than this, I don't see what was not clear about its semantics.
> And I can't see any reason why we couldn't clarify the semantics.

The action alist is flat - whichever entry comes first is used even if
it is not pertinent to the action chosen.  If the action chosen is say
'display-buffer-in-previous-window', the frames to investigate are
currently specified by a 'reusable-frames' entry.  If no such entry is
present, we could check for a 'same-frame' entry.  But what should
'display-buffer' do when both entries are present with 'same-frame'
coming first?  And how would 'display-buffer-use-some-window' and
'display-buffer-use-least-recent-window' handle the similar case with a
'lru-frames' and a 'same-frame' entry both present?

Now if you want 'same-frame' to prevail in either of these cases, it
will not suffice to rewrite the corresponding pieces of code where
another frame would be chosen.  Any application that really needs a
window on another frame will then have to provide a (same-frame . nil)
entry.

If you want 'same-frame' to not prevail in these cases, you probably
mean that it should only inhibit popping up a new frame via
'display-buffer-pop-up-frame'.  Again applications that want to pop up a
new frame would then have to provide a (same-frame . nil) entry.

>> As for a new window on the selected frame, use
>> 'display-buffer-pop-up-window'.  As for any other window on the
>> selected frame, use either ‘display-buffer-use-some-window’ or
>> ‘display-buffer-use-least-recent-window’ with a nil 'lru-frames'
>> action alist entry.
>
> `same-frame` was not quite like any of those, it said "keep using the
> default set of options in the same order of preferences, except that if
> at all possible, skip those options which end up displaying the buffer
> in another frame".

The proof of this pudding is in clarifying the "if at all possible" and
explaining any new special behavior in the manual.

martin

Previous Next

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