Re: master ce4ec17: Fix display-buffer-override-next-command to call action only once (bug#39722)

[Juri Linkov]

>>>>     Fix display-buffer-override-next-command to call action only once 
>>>> (bug#39722)
>>> How do prefix commands using `display-buffer-override-next-command`
>>> interact with other prefix commands such as `C-u`?
>> They play nicely with all prefix commands, and even with the minibuffer:
>> display-buffer-override-next-command comes into play only after exiting
>> the minibuffer.
>
> I'm not sure how.  I think `C-x 4 4` followed by `C-u` will work thanks
> to the (eq this-command command) check (because
> `prefix-command-preserve-state` does (setq this-command last-command)),
> but I don't think the reverse will work.

Could you give an example of a key sequence where this might not work?

> Another problem I see in the code is that
> `display-buffer-override-next-command` does
>
>             (setq display-buffer-overriding-action
>                   (delq action display-buffer-overriding-action))
>        [...]
>     (push action display-buffer-overriding-action)))
>
> But `display-buffer-overriding-action` is not supposed to hold a list
> of actions.

display-buffer-overriding-action has exactly the same format as
display-buffer-fallback-action, and display-buffer-fallback-action
holds a list of actions:

  (defconst display-buffer-fallback-action
    '((display-buffer--maybe-same-window  ;FIXME: why isn't this redundant?
       display-buffer-reuse-window
       display-buffer--maybe-pop-up-frame-or-window
       display-buffer-in-previous-window
       display-buffer-use-some-window
       ;; If all else fails, pop up a new frame.
       display-buffer-pop-up-frame))
    "Default fallback action for `display-buffer'.
  This is the action used by `display-buffer' if no other actions
  have been specified, for example, by the user options
  `display-buffer-alist' or `display-buffer-base-action', or they
  all fail.  It should never be set by programs or users.  See
  `display-buffer'.")

>>> Any chance this can be merged/unified with `other-frame-window` code?
>> What features do you miss from other-frame-window?
>
> I'm not really worried about features but more about the code and about
> what we've learned about the detailed interactions (i.e. trying to avoid
> reinventing the same not-quite-circular wheel).  In terms of features
> (besides the extra transient keymap which allows the use of shorter `C-x
> 4` and `C-x 5` prefixes and special bindings under those prefixes)
> I suspect that there's the echo area feedback that's missing, tho I'm
> not sure it works really well yet in `other-frame-window`.

Incidentally, the echo area feedback and the extra transient keymap
is exactly what is currently discussed for project-switch-project
where `C-x p p` displays a short menu in the echo area and reads keys
to run commands from the project.el prefix keymap.  But I'm not sure
if `C-x 4` and `C-x 5` should be bound to a command like that.