[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42210: Add -other-window variants of project-prefix-map commands
From: |
Sean Whitton |
Subject: |
bug#42210: Add -other-window variants of project-prefix-map commands |
Date: |
Sun, 05 Jul 2020 18:58:17 -0700 |
Hello Juri,
Thanks for taking a look.
On Mon 06 Jul 2020 at 03:19AM +03, Juri Linkov wrote:
>> Here is a patch implementing commands under C-x 4 p. If the approach is
>> thought sound I can also prepare patches for C-x 5 p and C-x t p.
>>
>> I have tested the attached change except for the autoload cookies which
>> I am not sure will work with my new macro. And I'm not sure I should be
>> doing this with a macro instead of a function which calls fset -- please
>> advise.
>
> Thanks for the patch. On emacs-devel you said that rather than add
> definitions of project-find-file-other-window, etc.
> display-buffer-override-next-command could be used. But there is no
> display-buffer-override-next-command in your patch, and definitions of
> project-find-file-other-window etc. are still added (with the help of macro).
Yeah. After thinking about it a bit more I thought that this would be
more consistent with both the way the other C-x 4 commands work and how
the C-x p subcommands work -- i.e., it's just an ordinary keymap.
Additionally, my approach means that the -other-window functions are
available to be called from lisp, just as switch-to-buffer-other-window
and find-file-other-window already are, which might be useful.
>From my perspective, the use of define-other-window-command is
sufficient to resolve my concerns (posted to emacs-devel) about having to
define all the functions. And I think that the macro could be useful in
user init files and maybe elsewhere.
> Would it be possible to define the 'C-x 4 p' map the same way as
> 'C-x p p' is defined? There is a patch in https://debbugs.gnu.org/41890#127
> to use the default project keymap 'C-x p' in 'C-x p p'. You could try to
> use the same keymap in 'C-x 4 p', and wrap the command call with
> display-buffer-override-next-command.
I could give it a shot, but wouldn't it be less useful, since the
-other-window functions would no longer be available to be called from
lisp?
As I say, I think the concerns about having to define the functions is
resolved by define-other-window-command (or whatever it ends up called).
Maybe you could explain why you think doing it like C-x p p would be
better. Thanks again.
--
Sean Whitton