Add -other-{window,frame} variants of project-prefix-map commands

Add -other-{window,frame} variants of project-prefix-map commands

[Sean Whitton]

Hello,

It seems like it would be a good idea to have

C-x 4 p f
be like
C-x 4 4 C-x p f

C-x 5 p e
be like
C-x 5 5 C-x p e

etc., since many of the commands in project-prefix-map involve switching
to another buffer.  Certainly project-switch-project, project-find-file
and project-switch-to-buffer would be wanted.

Rather than add definitions of project-find-file-other-window,
project-eshell-other-frame etc., maybe
`display-buffer-override-next-command' could be used so that pressing
C-x 4 p really is just like pressing C-x 4 4 C-x p.

The only disadvantage I can see is that commands like C-x 4 p k would
also be bound and those don't really make sense.

What would be the cleanest way to try to do this?

Thanks.

-- 
Sean Whitton

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Stephen Leake]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> It seems like it would be a good idea to have
>
> C-x 4 p f
> be like
> C-x 4 4 C-x p f
>
> C-x 5 p e
> be like
> C-x 5 5 C-x p e
>
> etc., since many of the commands in project-prefix-map involve switching
> to another buffer.  Certainly project-switch-project, project-find-file
> and project-switch-to-buffer would be wanted.
>
> Rather than add definitions of project-find-file-other-window,
> project-eshell-other-frame etc., maybe
> `display-buffer-override-next-command' could be used so that pressing
> C-x 4 p really is just like pressing C-x 4 4 C-x p.
>
> The only disadvantage I can see is that commands like C-x 4 p k would
> also be bound and those don't really make sense.
>
> What would be the cleanest way to try to do this?

Install the GNU ELPA package other-frame-window; that adds those key
prefixes to all commands.


-- 
-- Stephe

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Sean Whitton]

Hello Stephen,

On Fri 03 Jul 2020 at 10:34PM -07, Stephen Leake wrote:

> Install the GNU ELPA package other-frame-window; that adds those key
> prefixes to all commands.

Thank you for the reference, but I'm talking about augmenting the new
C-x p bindings in core Emacs, not looking for a solution I can install
locally.

-- 
Sean Whitton

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Stephen Leake]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello Stephen,
>
> On Fri 03 Jul 2020 at 10:34PM -07, Stephen Leake wrote:
>
>> Install the GNU ELPA package other-frame-window; that adds those key
>> prefixes to all commands.
>
> Thank you for the reference, but I'm talking about augmenting the new
> C-x p bindings in core Emacs, not looking for a solution I can install
> locally.

You could incorporate other-frame-window into core. We could then keep
it as a core elpa package, or delete the elpa package.

-- 
-- Stephe

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Juri Linkov]

>> It seems like it would be a good idea to have
>>
>> C-x 4 p f
>> be like
>> C-x 4 4 C-x p f
>>
>> C-x 5 p e
>> be like
>> C-x 5 5 C-x p e
>>
>> etc., since many of the commands in project-prefix-map involve switching
>> to another buffer.  Certainly project-switch-project, project-find-file
>> and project-switch-to-buffer would be wanted.
>>
>> Rather than add definitions of project-find-file-other-window,
>> project-eshell-other-frame etc., maybe
>> `display-buffer-override-next-command' could be used so that pressing
>> C-x 4 p really is just like pressing C-x 4 4 C-x p.
>>
>> The only disadvantage I can see is that commands like C-x 4 p k would
>> also be bound and those don't really make sense.
>>
>> What would be the cleanest way to try to do this?
>
> Install the GNU ELPA package other-frame-window; that adds those key
> prefixes to all commands.

The advantage of other-frame-window is the dedicated keymap that
makes all commands to display their buffers in other-window/frame.
I think that Emacs core can't have such keymap.

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Stefan Monnier]

> The advantage of other-frame-window is the dedicated keymap that
> makes all commands to display their buffers in other-window/frame.
> I think that Emacs core can't have such keymap.

What makes you think Emacs core can't have such a keymap?


        Stefan

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Juri Linkov]

>> The advantage of other-frame-window is the dedicated keymap that
>> makes all commands to display their buffers in other-window/frame.
>> I think that Emacs core can't have such keymap.
>
> What makes you think Emacs core can't have such a keymap?

I assumed it would be too monumental change.  But maybe it's not.
What it's necessary to do is:

1. Bind ‘C-x 4’ to a new command that will set a transient value of
   display-buffer-overriding-action and a transient keymap to the
   other-window commands keymap.

2. Enable switch-to-buffer-obey-display-actions by default,
   so all buffer-switching commands (e.g. ‘C-h C-t’, ‘C-h C-p’, ‘C-h n’
   and many other such commands) will obey display-buffer-overriding-action.

RE: Add -other-{window, frame} variants of project-prefix-map commands

[Drew Adams]

> What it's necessary to do is:
> 
> 1. Bind ‘C-x 4’ to a new command that will set a transient value of
>    display-buffer-overriding-action and a transient keymap to the
>    other-window commands keymap.
> 
> 2. Enable switch-to-buffer-obey-display-actions by default,
>    so all buffer-switching commands (e.g. ‘C-h C-t’, ‘C-h C-p’, ‘C-h n’
>    and many other such commands) will obey display-buffer-overriding-action.

Please don't do that.

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Stefan Monnier]

>> What makes you think Emacs core can't have such a keymap?
> I assumed it would be too monumental change.

`other-frame-window` makes an effort to preserve the old behavior.
Inevitably, there are some changes, but I don't think these are drastic
enough to qualify as "monumental" or to rule out the change.

> 1. Bind ‘C-x 4’ to a new command that will set a transient value of
>    display-buffer-overriding-action and a transient keymap to the
>    other-window commands keymap.

That's what `other-frame-window` offers (and to a lesser extent the
current `C-x 4 4` as well).

> 2. Enable switch-to-buffer-obey-display-actions by default,
>    so all buffer-switching commands (e.g. ‘C-h C-t’, ‘C-h C-p’, ‘C-h n’
>    and many other such commands) will obey display-buffer-overriding-action.

This seems like a largely orthogonal change, so I'd rather keep it out.


        Stefan

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Juri Linkov]

>>> What makes you think Emacs core can't have such a keymap?
>> I assumed it would be too monumental change.
>
> `other-frame-window` makes an effort to preserve the old behavior.
> Inevitably, there are some changes, but I don't think these are drastic
> enough to qualify as "monumental" or to rule out the change.

It seems the biggest challenge that needs to be solved before making
any changes in core Emacs is how to keep backward-compatibility with
keybindings added by users to the existing keymap ctl-x-4-map.
I guess it should be fine to run -other-window commands from these keymaps
because display-buffer-overriding-action will override their default
behavior but will provide the same outcome.  Then maybe a new command bound
to `C-x 4` could just introspect ctl-x-4-map and run its commands as is.

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Stefan Monnier]

> It seems the biggest challenge that needs to be solved before making
> any changes in core Emacs is how to keep backward-compatibility with
> keybindings added by users to the existing keymap ctl-x-4-map.

`other-frame-window` doesn't make any effort to handle that, indeed.
It provides `ofw-transient-map` instead.

I believe we could live with this kind of backward incompatibility.

> Then maybe a new command bound to `C-x 4` could just introspect
> ctl-x-4-map and run its commands as is.

We could try and manually combine ctl-x-5-map and ctl-x-4-map into
`ofw-transient-map` in `ofw--set-prefix`, but I'm not sure it's worth
the hassle.

Note also that the tension between parsing `C-x 4 FOO` as "lookup FOO in
`ctl-x-4-map` (or in `ofw-transient-map`)" and "lookup FOO in the normal
way", which is why in `ofw--set-prefix` we do:

  ;; FIXME: Setup a transient map to reproduce the behavior of the `C-x 4/5'
  ;; prefix keys, but only do it in "regular" buffers.  In special buffers,
  ;; these extra bindings may be more annoying than anything, e.g. in Gnus's
  ;; summary buffer `a' open a new message buffer, so we'd want `C-x
  ;; 5 a' to open it in a new frame, but instead of calling
  ;; add-change-log-entry.
  (when (eq (key-binding [?a]) 'self-insert-command) ;Heuristic!
    (set-transient-map ofw-transient-map)))


-- Stefan

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Juri Linkov]

> Note also that the tension between parsing `C-x 4 FOO` as "lookup FOO in
> `ctl-x-4-map` (or in `ofw-transient-map`)" and "lookup FOO in the normal
> way", which is why in `ofw--set-prefix` we do:
>
>  ;; FIXME: Setup a transient map to reproduce the behavior of the `C-x 4/5'
>  ;; prefix keys, but only do it in "regular" buffers.  In special buffers,
>  ;; these extra bindings may be more annoying than anything, e.g. in Gnus's
>  ;; summary buffer `a' open a new message buffer, so we'd want `C-x
>  ;; 5 a' to open it in a new frame, but instead of calling
>  ;; add-change-log-entry.

The latter ("lookup FOO in the normal way") is handled now by `C-x 5 5 a`,
so the transient map for the former ("lookup FOO in `ctl-x-4-map`")
could contain only cherry-picked shorthands to reduce longer key sequences
like `C-x 5 5 C-x C-f` to just `C-x 5 f`.

Maybe even it could employ some heuristic to automatically deduce
the transient map based on the existing `C-x` keymap.  For example,
from `C-x p b` (project-switch-to-buffer) it could build a new key
sequence `C-x 5 p b`, etc.  This could help to close bug#42210.

Re: Add -other-{window, frame} variants of project-prefix-map commands

[Juri Linkov]

>> Note also that the tension between parsing `C-x 4 FOO` as "lookup FOO in
>> `ctl-x-4-map` (or in `ofw-transient-map`)" and "lookup FOO in the normal
>> way", which is why in `ofw--set-prefix` we do:
>>
>>  ;; FIXME: Setup a transient map to reproduce the behavior of the `C-x 4/5'
>>  ;; prefix keys, but only do it in "regular" buffers.  In special buffers,
>>  ;; these extra bindings may be more annoying than anything, e.g. in Gnus's
>>  ;; summary buffer `a' open a new message buffer, so we'd want `C-x
>>  ;; 5 a' to open it in a new frame, but instead of calling
>>  ;; add-change-log-entry.
>
> The latter ("lookup FOO in the normal way") is handled now by `C-x 5 5 a`,

I meant that in Gnus's summary buffer `C-x 5 5 a` opens a new message buffer
in a new frame.

> Maybe even it could employ some heuristic to automatically deduce
> the transient map based on the existing `C-x` keymap.  For example,
> from `C-x p b` (project-switch-to-buffer) it could build a new key
> sequence `C-x 5 p b`, etc.  This could help to close bug#42210.

Unfortunately, it can automatically turn `C-x C-f` only into `C-x 5 C-f`,
not to `C-x 5 f`, so probably no such automatic translation is possible.