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

[martin rudalics]

> Here's a first candidate patch.
>
> I introduced a new function `display-buffer--pop-up-frame` so as to
> ignore `inhibit-new-frame` as a last resort.

Good idea.

> I also modified `display-buffer--other-frame-action` to use
> `display-buffer--pop-up-frame`, because it seems this is used only(?) in
> response to an explicit user request where the user does expect a new
> frame (like `C-x 5 b`) and so it seems to make sense to override even an
> `inhibit-new-frame` coming from `display-buffer-alist`.

>  (defvar display-buffer--other-frame-action
>    '((display-buffer-reuse-window
> -     display-buffer-pop-up-frame)
> +     display-buffer--pop-up-frame)
>      (reusable-frames . 0)
>      (inhibit-same-window . t))

This one is messy anyway but I never tried to tinker with it.  After
all, "0" means to probe any frame around _including_ the selected one.
It probably should call 'display-buffer-use-some-frame' and maybe also
'display-buffer-use-least-recent-window' with a suitable 'lru-frames'
entry.  Just that our FRAMES argument nomenclature does not allow to
exclude the selected frame from the list of frames to probe or return.

> +(defun display-buffer--pop-up-frame (buffer alist)
> +  "Like `display-buffer--pop-up-frame' but ignores `inhibit-new-frame'.

This seems to have an extra "-".

> PS: Am I the only one who finds it confusing how some functions
> named `display-buffer-<foo>` are meant to be used from the ACTIONs
> (i.e. from within `display-buffer`) while others are implemented on top
> of `display-buffer` (and thus should not be used within ACTIONS)?
> Could we try and find a clear naming convention to distinguish the two,
> or am I even more confused than I thought and several of those functions
> can be used either way?

Do you mean 'display-buffer-override-next-command' and
'display-buffer-record-window'?  As for the latter, the reason was that
applications might want to call this in their code for recording the
window used so it's not meant to be strictly window.el internal.  If you
mean something else, please give one or two examples of such confusing
functions.

martin