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

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

[Stefan Monnier]

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

Any chance this can be merged/unified with `other-frame-window` code?


        Stefan

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.

> Any chance this can be merged/unified with `other-frame-window` code?

What features do you miss from other-frame-window?

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

[Stefan Monnier]

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

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.

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


        Stefan

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.

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

[Stefan Monnier]

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

`C-u C-x 5 5 C-x =` won't display the extra info requested by the `C-u`.

You can still get it with `C-x 5 5 C-u C-x =`, but the user shouldn't
have to remember in which order prefix commands need to be entered.

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

Look again!  This is not a list of functions: it's a cons cell whose car
is a list of functions.

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

I was referring to the each area info also displayed by `C-u`, via
`prefix-command-echo-keystrokes-functions`.  Nothing fancy like a menu:
just a brief mention to reflect the fact that a prefix command is "about
to be applied".


        Stefan

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

[Juri Linkov]

>>> 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?
>
> `C-u C-x 5 5 C-x =` won't display the extra info requested by the `C-u`.
>
> You can still get it with `C-x 5 5 C-u C-x =`, but the user shouldn't
> have to remember in which order prefix commands need to be entered.

The feature was intentionally designed this way for several reasons:

1. it should be easier for the users to build the key sequence
   when the prefix is in front of the main command key sequence,
   not before the command that requests a new window/frame;

2. to allow adding arguments to the commands `C-x 4 4` and `C-x 5 5`.

The design was based on the existing command `windmove-display-in-direction`
where the prefix arg can be given to not select the displayed window.

Similarly, the prefix arg could be added to `C-x 4 4` and `C-x 5 5`
to request displaying the buffer in another window/frame,
but not to select the displayed window.

Then `C-u C-x 5 5 C-u C-x =` will display the Help buffer in another frame
without selecting it.

>> 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))
>
> Look again!  This is not a list of functions: it's a cons cell whose car
> is a list of functions.

It seems currently it works because no other code tries to modify
display-buffer-overriding-action, but really functions should be added
to the car of display-buffer-overriding-action, or maybe even better
not to add but replace display-buffer-overriding-action with own value.

>> 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.
>
> I was referring to the each area info also displayed by `C-u`, via
> `prefix-command-echo-keystrokes-functions`.  Nothing fancy like a menu:
> just a brief mention to reflect the fact that a prefix command is "about
> to be applied".

Currently `C-x 5 5` just displays the message before the next command:

  "Display next command buffer in a new frame..."

but using `prefix-command-echo-keystrokes-functions` it could display
"[other-frame]" like other-frame-window does for every following key press.

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

[Stefan Monnier]

> The feature was intentionally designed this way for several reasons:
> 1. it should be easier for the users to build the key sequence
>    when the prefix is in front of the main command key sequence,
>    not before the command that requests a new window/frame;

I don't think supporting only one of the two orders can be claimed to
make things easier for the user.

> 2. to allow adding arguments to the commands `C-x 4 4` and `C-x 5 5`.

That's the problem, indeed.  It introduces two different kinds of
prefixes: those that only apply to "normal commands" and those that also
apply to (some) prefixes.

I'd rather try and avoid this complexity because I think it will become
problematic as more prefix commands get written.  E.g. the ordering
problem doesn't only affect `C-u` but all other prefix commands, such as
`C-x RET c` (there currently aren't others bundled with Emacs, but there
are others out there).


        Stefan

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

[Juri Linkov]

>> 2. to allow adding arguments to the commands `C-x 4 4` and `C-x 5 5`.
>
> That's the problem, indeed.  It introduces two different kinds of
> prefixes: those that only apply to "normal commands" and those that also
> apply to (some) prefixes.
>
> I'd rather try and avoid this complexity because I think it will become
> problematic as more prefix commands get written.  E.g. the ordering
> problem doesn't only affect `C-u` but all other prefix commands, such as
> `C-x RET c` (there currently aren't others bundled with Emacs, but there
> are others out there).

Hmm, I didn't know that set-buffer-file-coding-system supports a prefix arg:
`C-u C-x RET f`.

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

[Juri Linkov]

>>> 2. to allow adding arguments to the commands `C-x 4 4` and `C-x 5 5`.
>>
>> That's the problem, indeed.  It introduces two different kinds of
>> prefixes: those that only apply to "normal commands" and those that also
>> apply to (some) prefixes.
>>
>> I'd rather try and avoid this complexity because I think it will become
>> problematic as more prefix commands get written.  E.g. the ordering
>> problem doesn't only affect `C-u` but all other prefix commands, such as
>> `C-x RET c` (there currently aren't others bundled with Emacs, but there
>> are others out there).
>
> Hmm, I didn't know that set-buffer-file-coding-system supports a prefix arg:
> `C-u C-x RET f`.

BTW, there is also a new command 'same-window-prefix' to request
displaying the next command's buffer in the same window to override
the setting that would otherwise display the buffer in another window.

But the problem is that currently it's not bound, and I can't find
a good mnemonic keybinding.

'C-x 4 0' is already taken.
'C-x 4 1' could be reserved for another command that would delete other windows
          before displaying the next buffer in the remaining single window.

Maybe 'C-x 4 s'?

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

[Stefan Monnier]

>>> I'd rather try and avoid this complexity because I think it will become
>>> problematic as more prefix commands get written.  E.g. the ordering
>>> problem doesn't only affect `C-u` but all other prefix commands, such as
>>> `C-x RET c` (there currently aren't others bundled with Emacs, but there
>>> are others out there).
>>
>> Hmm, I didn't know that set-buffer-file-coding-system supports a prefix arg:
>> `C-u C-x RET f`.

Not sure how that relates to the previous paragraph.

> BTW, there is also a new command 'same-window-prefix' to request
> displaying the next command's buffer in the same window to override
> the setting that would otherwise display the buffer in another window.

Yes, I like it (it's been on my todo list for other-frame-window).

> But the problem is that currently it's not bound, and I can't find
> a good mnemonic keybinding.

Same problem here.  It's part of the low motivation to work on that todo
item ;-)

> 'C-x 4 0' is already taken.
> 'C-x 4 1' could be reserved for another command that would delete other windows
>           before displaying the next buffer in the remaining single window.
>
> Maybe 'C-x 4 s'?

Since I use `C-x 4` instead of `C-x 4 4`, I'd say that `C-x 1` would be
the "natural" choice, but that's also already taken :-(


        Stefan

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

[Juri Linkov]

>>>> I'd rather try and avoid this complexity because I think it will become
>>>> problematic as more prefix commands get written.  E.g. the ordering
>>>> problem doesn't only affect `C-u` but all other prefix commands, such as
>>>> `C-x RET c` (there currently aren't others bundled with Emacs, but there
>>>> are others out there).
>>>
>>> Hmm, I didn't know that set-buffer-file-coding-system supports a prefix arg:
>>> `C-u C-x RET f`.
>
> Not sure how that relates to the previous paragraph.

I just discovered a prefix command that supports a prefix arg.
This doesn't mean of course that it should set a precedent
for other commands to follow.

>> BTW, there is also a new command 'same-window-prefix' to request
>> displaying the next command's buffer in the same window to override
>> the setting that would otherwise display the buffer in another window.
>
> Yes, I like it (it's been on my todo list for other-frame-window).
>
>> But the problem is that currently it's not bound, and I can't find
>> a good mnemonic keybinding.
>
> Same problem here.  It's part of the low motivation to work on that todo
> item ;-)
>
>> 'C-x 4 0' is already taken.
>> 'C-x 4 1' could be reserved for another command that would delete other windows
>>           before displaying the next buffer in the remaining single window.
>>
>> Maybe 'C-x 4 s'?
>
> Since I use `C-x 4` instead of `C-x 4 4`, I'd say that `C-x 1` would be
> the "natural" choice, but that's also already taken :-(

But you can still use `C-x 4 1` as a submap of your `C-x 4` map where commands
of the submap will display the buffer in the same window.

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

[Stefan Monnier]

>>>>> I'd rather try and avoid this complexity because I think it will become
>>>>> problematic as more prefix commands get written.  E.g. the ordering
>>>>> problem doesn't only affect `C-u` but all other prefix commands, such as
>>>>> `C-x RET c` (there currently aren't others bundled with Emacs, but there
>>>>> are others out there).
>>>> Hmm, I didn't know that set-buffer-file-coding-system supports a prefix arg:
>>>> `C-u C-x RET f`.
>> Not sure how that relates to the previous paragraph.
> I just discovered a prefix command that supports a prefix arg.
> This doesn't mean of course that it should set a precedent
> for other commands to follow.

AFAIK `C-x RET f` is not a prefix command.

>> Since I use `C-x 4` instead of `C-x 4 4`, I'd say that `C-x 1` would be
>> the "natural" choice, but that's also already taken :-(
> But you can still use `C-x 4 1` as a submap of your `C-x 4` map where commands
> of the submap will display the buffer in the same window.

Hmm... maybe `C-x 4 1` is a good choice for `same-window-prefix`.


        Stefan

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

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Since I use `C-x 4` instead of `C-x 4 4`, I'd say that `C-x 1` would be
>>> the "natural" choice, but that's also already taken :-(
>> But you can still use `C-x 4 1` as a submap of your `C-x 4` map where commands
>> of the submap will display the buffer in the same window.
>
> Hmm... maybe `C-x 4 1` is a good choice for `same-window-prefix`.

As a random passerby who thinks C-x 4 4 and C-x 5 5 are the best thing
since sliced bread: yes please.

Thank you for these new commands.

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

[Juri Linkov]

>>>>>> I'd rather try and avoid this complexity because I think it will become
>>>>>> problematic as more prefix commands get written.  E.g. the ordering
>>>>>> problem doesn't only affect `C-u` but all other prefix commands, such as
>>>>>> `C-x RET c` (there currently aren't others bundled with Emacs, but there
>>>>>> are others out there).
>>>>> Hmm, I didn't know that set-buffer-file-coding-system supports a prefix arg:
>>>>> `C-u C-x RET f`.
>>> Not sure how that relates to the previous paragraph.
>> I just discovered a prefix command that supports a prefix arg.
>> This doesn't mean of course that it should set a precedent
>> for other commands to follow.
>
> AFAIK `C-x RET f` is not a prefix command.

Oops, sorry, I forgot it's not a prefix command.

>>> Since I use `C-x 4` instead of `C-x 4 4`, I'd say that `C-x 1` would be
>>> the "natural" choice, but that's also already taken :-(
>> But you can still use `C-x 4 1` as a submap of your `C-x 4` map where commands
>> of the submap will display the buffer in the same window.
>
> Hmm... maybe `C-x 4 1` is a good choice for `same-window-prefix`.

So now `same-window-prefix` is bound to `C-x 4 1`.