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

[Stefan Monnier]

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

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

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

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 :-)

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

Same reasoning here.

> If you want 'same-frame' to not prevail in these cases, you probably

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.

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

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.

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

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

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


        Stefan