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

From: martin rudalics <[email-masked]>
Date: Thu, 23 Nov 2023 10:59:55 +0100

>> and the customization types that use them (IIRC either you or Chong
 >> invented them).
 >
 > The customization type is not used for them (they are internal
 > variables, not user-facing nor Customizable).

I meant their use in, for example,

(defcustom display-comint-buffer-action display-buffer--same-window-action

 >> 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.
 >
 > Ah, yes, I see.
 > IIUC, the "inhibit-new-frame" semantics seems less susceptible to this
 > problem then the "same-frame", no?

When I type M-x to invoke a custom function for displaying a buffer, I'd
probably want 'inhibit-new-frame' to do what it advertises regardless of
whether I'm in a stand-alone minibuffer frame or in a normal minibuffer
window.  But we could add a separate value for 'inhibit-new-frame' like
'may-use-last-nonminibuffer-frame' to regulate that.

martin