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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 67249 <at> debbugs.gnu.org
Subject: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
Date: Sat, 18 Nov 2023 22:52:45 -0500

>> 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-*`?

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

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.

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


        Stefan

Previous Next

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