Subject: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`

From: martin rudalics <[email-masked]>
Date: Mon, 20 Nov 2023 10:15:55 +0100

> Right, so it should probably have been called something like "no new
 > frame".

We should prominently mention that in the manual then.  BTW creating a
new frame is always one last resort of 'display-buffer'.

 > I don't see a big problem here: we could choose `same-frame` to imply
 > that `reusable-frames` is nil, or we could choose to ignore
 > `same-frame`.  Since the code that adds `(same-frame . t)` could just as well
 > also add `(reusable-frames)`, the first choice is less flexible
 > than the second (tho it allows overriding a higher-precedence
 > `reusable-frames` setting), so I'd go with the first choice, which also
 > has the advantage of not requiring any code modification :-)

So a (same-frame . t) entry would simply auto-translate to a pair of
(reusable-frames . nil) (lru-frames . nil) entries?

 > I don't necessarily want a particular behavior.  I want to provide
 > a similar functionality, within the constraints of what we can define
 > and implement sanely.
 >
 > So no, I don't necessarily want it to prevail over those other entries.

With the conclusion above it would prevail.

 >> mean that it should only inhibit popping up a new frame via
 >> 'display-buffer-pop-up-frame'.
 >
 > That was my conclusion when I looked at the code (concretized in
 > my PoC patch).

OK.

 > Another approach is to provide a new action.
 > This could be a `display-buffer-same-frame` action which tries its best
 > to use the selected frame.
 > I suspect in many cases the actual intention of `same-frame` was to keep
 > the buffer nearby, so I suspect we could also replace `same-frame` with
 > a `display-buffer-nearby` action.
 >
 > The advantage of an action is that we don't need to decide how existing
 > actions interact with it.

We could add a 'display-buffer--same-frame-action' variable.

 >> Again applications that want to pop up a new frame would then have to
 >> provide a (same-frame . nil) entry.
 >
 > That would seem fair game, IMO.

It means a change in existing code.  Till now, applications were on the
safe side in this regard since they could always blame others for using
an obsolete feature.

 > I suspect the main exception would be minibuffer-only frames, but we
 > could get fancier if we feel like it (like when the selected frame can't
 > accommodate the `window-min-width` and `window-min-height`, or when we
 > set `inhibit-same-window` (or the selected window is dedicated) and the
 > frame's sole window can't be split).

Do you anywhere see 'display-buffer' choose a minibuffer-only frame?
I'm aware of the fact that the

(window--frame-usable-p (last-nonminibuffer-frame))

is broken when a minibuffer-only frame is the only frame left but so far
nobody complained ...

martin