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

From: martin rudalics <[email-masked]>
Date: Wed, 22 Nov 2023 09:02:03 +0100

> We could, but we could also define the semantics of `same-frame` to have
 > no effect on frame re-use (it would actually be closer to the current
 > semantics).  If so, it'd be best to find another name for it along the
 > lines of "no-new-frame".

Agreed.  'inhibit-pop-up-frame' or 'inhibit-new-frame' would be more in
accordance with 'inhibit-same-window' and 'inhibit-switch-frame'.

 >>>> 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.
 >> It could do what I meant above - translate 'same-frame' internally.
 >
 > What is "it"?  `display-buffer--same-frame-action`?
 > Without knowing where you'd use such a variable, it's hard for me to
 > guess what you mean by that.

It would be similar to 'display-buffer--same-window-action' and
'display-buffer--other-frame-action' and could be used in the same way.
But I'm not familiar with these variables and the customization types
that use them (IIRC either you or Chong invented them).

 > I suspect it might be sufficient, but it would deserve a better name so
 > users don't get the wrong impression that it will affect reuse on
 > other frames.
 >
 > So you think the patch I sent is actually more-or-less acceptable
 > (modulo documentation and finding a better name)?

Yes.

 >> When the selected frame is a minibuffer-only frame, 'display-buffer'
 >> usually tries to think of 'last-nonminibuffer-frame' as the selected
 >> frame.  So probably 'same-frame' should do the same.
 >
 > Sounds like this is compatible to my suggestion that it's OK to ignore
 > `same-frame` when the selected frame is a minibuffer-only frame.
 >
 >> But all I can do is to hint at inconsistencies in your proposal.
 >
 > Not sure what's the inconsistency there.

If OT1H 'same-frame' is ignored when the selected frame is a
minibuffer-only frame (so a new frame gets popped up instead) and OTOH
the remaining action functions do use the last non-minibuffer frame in
such case, then the behavior of 'display-buffer' is inconsistent in my
regard.

martin