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

[martin rudalics]

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