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

[Stefan Monnier]

> BTW creating a new frame is always one last resort of 'display-buffer'.

That depends on the rest of the config, AFAIK.
I tried the patch I sent on some of my config and it did have an effect
(e.g. when I open `M-x calendar`, depending the `same-frame` I either
get one frame with *Calendar* and another with `diary` or I get
a single frame with both.  Both windows are dedicated).

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

[ Hmm... I'm curious how you interpreted what I wrote to reach
  that conclusion.  ]
No, I meant the opposite: the users who want to override
`reusable-frames` and `lru-frames` need to add all three

    (same-frame . t)
    (reusable-frames . nil)
    (lru-frames . nil)

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

I don't really know what that suggestion means.
The `--` suggests it'd be some internal detail of `window.el` whereas
I thought we're discussing the externally visible API and semantics.

>>> 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 don't see why you think it'd require any change in existing code: the
ones who set `same-frame` get what they ask for.

>> 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 not talking about `display-buffer` choosing a minibuffer-only frame.
I'm saying that when the selected-frame is a minibuffer-only frame, it's OK
to ignore the `same-frame` request.


        Stefan