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

[martin rudalics]

> 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