GNU bug report logs - #70577
[PATCH] New command other-project-prefix

Previous Next

To reply to this bug, email your comments to 70577 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] New command other-project-prefix
Date: Fri, 26 Apr 2024 06:01:35 +0300

X-Debbugs-Cc: Juri Linkov <juri <at> linkov.net>

This is based on Juri's patch in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#161, but the idea is 
more focused: to switch the order of events, and first read the full key 
sequence, and then prompt for the project and the command arguments. 
Like we also discussed in the past.

And to try to reuse the even loop in the more natural way. 
Unfortunately, 'C-h' doesn't work here (when called in the middle of the 
sequence) - I'm not sure why. The rest of the behavior seems to work as 
expected.

So this can be a new alternative for the 'C-x p p' binding as well.

Regarding the the use of advice, I didn't find a better way to plug 
(funcall project-prompter) this late. Too complex for pre-command-hook.

Thoughts welcome.

Message #8 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Fri, 26 Apr 2024 09:09:35 +0300

> This is based on Juri's patch in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#161, but the idea is
> more focused: to switch the order of events, and first read the full key
> sequence, and then prompt for the project and the command arguments. Like
> we also discussed in the past.

I'm not a fan of reading the full key sequence bypassing the event loop.

> And to try to reuse the even loop in the more natural way. Unfortunately,
> 'C-h' doesn't work here (when called in the middle of the sequence) - I'm
> not sure why. The rest of the behavior seems to work as expected.

'C-h' can't work since 'C-x p p' is bound to a command.

> So this can be a new alternative for the 'C-x p p' binding as well.

I guess there could be 2 new alternative options for 'project-switch-commands':

1. read the full key sequence
2. use the event loop with set-transient-map

Although I'm already completely content with the existing option
'project-prefix-or-any-command' of 'project-switch-commands'.

Message #11 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Fri, 26 Apr 2024 13:59:48 +0300

On 26/04/2024 09:09, Juri Linkov wrote:
>> This is based on Juri's patch in
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#161, but the idea is
>> more focused: to switch the order of events, and first read the full key
>> sequence, and then prompt for the project and the command arguments. Like
>> we also discussed in the past.
> 
> I'm not a fan of reading the full key sequence bypassing the event loop.

That's what the current code does. While the patch tries to change that.

>> And to try to reuse the even loop in the more natural way. Unfortunately,
>> 'C-h' doesn't work here (when called in the middle of the sequence) - I'm
>> not sure why. The rest of the behavior seems to work as expected.
> 
> 'C-h' can't work since 'C-x p p' is bound to a command.

Hmm, I wonder how hard it'd be to change that.

>> So this can be a new alternative for the 'C-x p p' binding as well.
> 
> I guess there could be 2 new alternative options for 'project-switch-commands':
> 
> 1. read the full key sequence
> 2. use the event loop with set-transient-map
> 
> Although I'm already completely content with the existing option
> 'project-prefix-or-any-command' of 'project-switch-commands'.

This one is indeed an experiment. It just seems that being able to type 
the full sequence first is more ergonomically advantageous.

But overall this (adding a +1 alternative) is probably only worth it if 
we can make 'C-h' work like normal.

Message #14 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Fri, 26 Apr 2024 19:20:58 +0300

[Message part 1 (text/plain, inline)]

On 26/04/2024 13:59, Dmitry Gutov wrote:
> On 26/04/2024 09:09, Juri Linkov wrote:
>>> This is based on Juri's patch in
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#161, but the idea is
>>> more focused: to switch the order of events, and first read the full key
>>> sequence, and then prompt for the project and the command arguments. 
>>> Like
>>> we also discussed in the past.
>>
>> I'm not a fan of reading the full key sequence bypassing the event loop.
> 
> That's what the current code does. While the patch tries to change that.

Sorry, I forgot to attach the actual patch.

[other-project-prefix.diff (text/x-patch, attachment)]

Message #17 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Juri Linkov <juri <at> linkov.net>,
 emacs-devel <at> gnu.org
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 28 Apr 2024 13:13:13 +0100

Hello,

On Fri 26 Apr 2024 at 07:20pm +03, Dmitry Gutov wrote:

> +;;;###autoload
> +(defun other-project-prefix ()
> +  "\"Switch\" to another project before running an Emacs command.
> +Makes sure the next command invoked asks for the project to run it in."
> +  (interactive)
> +  (prefix-command-preserve-state)
> +  (letrec ((depth (minibuffer-depth))
> +           (echofun (lambda () "[switch-project]"))
> +           (around-fun
> +            (lambda (command &rest _args)
> +              (advice-remove this-command around-fun)
> +              (unless (or (eq this-command 'other-project-prefix)
> +                          (eq last-command-event help-char))
> +                (let ((root (funcall project-prompter)))
> +                  (if (or (string-prefix-p "project-"
> +                                           (symbol-name this-command))
> +                          (get this-command 'project-aware))
> +                      (let ((project-current-directory-override root))
> +                        (call-interactively command))
> +                    (let ((default-directory root))
> +                      (call-interactively command)))))))
> +           (prefun
> +            (lambda ()
> +              (unless (> (minibuffer-depth) depth)
> +                (remove-hook 'pre-command-hook prefun)
> +                (remove-hook 'prefix-command-echo-keystrokes-functions echofun)
> +                (when (and this-command (symbolp this-command))
> +                  (advice-add this-command :around around-fun))))))
> +    (add-hook 'pre-command-hook prefun)
> +    (add-hook 'prefix-command-echo-keystrokes-functions echofun)
> +    (let ((map (make-sparse-keymap)))
> +      (set-keymap-parent map project-prefix-map)
> +      ;; Doesn't work ;-(
> +      ;; (define-key map (vector help-char)
> +      ;;             (lambda () (interactive) (help-form-show)))
> +      (set-transient-map map))
> +    (message (concat "Type " (project--keymap-prompt) " or any global key"))))

In passing, this pattern where you letrec a hook that removes itself,
and also consider minibuffer-depth, is now in several places.
The one I am thinking of is vc-edit-next-command but I based that on
some code of Juri's somewhere.

It would be good to factor out a macro for this pattern, I think.

-- 
Sean Whitton

Message #20 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Juri Linkov <juri <at> linkov.net>,
 emacs-devel <at> gnu.org
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 28 Apr 2024 18:56:37 +0300

On 28/04/2024 15:13, Sean Whitton wrote:
> In passing, this pattern where you letrec a hook that removes itself,
> and also consider minibuffer-depth, is now in several places.
> The one I am thinking of is vc-edit-next-command but I based that on
> some code of Juri's somewhere.
> 
> It would be good to factor out a macro for this pattern, I think.

Makes sense. Maybe a helper function, not necessarily a macro.

Message #23 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 28 Apr 2024 19:51:04 +0300

> On 26/04/2024 13:59, Dmitry Gutov wrote:
>> On 26/04/2024 09:09, Juri Linkov wrote:
>>>> This is based on Juri's patch in
>>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#161, but the idea is
>>>> more focused: to switch the order of events, and first read the full key
>>>> sequence, and then prompt for the project and the command
>>>> arguments. Like
>>>> we also discussed in the past.
>>>
>>> I'm not a fan of reading the full key sequence bypassing the event loop.
>> That's what the current code does. While the patch tries to change that.
>
> Sorry, I forgot to attach the actual patch.

Thanks.

> +(defun other-project-prefix ()

Something is wrong here.  I bound 'other-project-prefix' to 'C-x p P'.
Then typing 'C-x p P C-x d' asked a directory name, then later
after selecting a project asked for the directory name again.
Then some advice remains unremoved.  Ok, will test more.

Message #26 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Mon, 29 Apr 2024 00:40:00 +0300

[Message part 1 (text/plain, inline)]

On 28/04/2024 19:51, Juri Linkov wrote:
>> On 26/04/2024 13:59, Dmitry Gutov wrote:
>>> On 26/04/2024 09:09, Juri Linkov wrote:
>>>>> This is based on Juri's patch in
>>>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#161, but the idea is
>>>>> more focused: to switch the order of events, and first read the full key
>>>>> sequence, and then prompt for the project and the command
>>>>> arguments. Like
>>>>> we also discussed in the past.
>>>>
>>>> I'm not a fan of reading the full key sequence bypassing the event loop.
>>> That's what the current code does. While the patch tries to change that.
>>
>> Sorry, I forgot to attach the actual patch.
> 
> Thanks.
> 
>> +(defun other-project-prefix ()
> 
> Something is wrong here.  I bound 'other-project-prefix' to 'C-x p P'.
> Then typing 'C-x p P C-x d' asked a directory name, then later
> after selecting a project asked for the directory name again.

Looks like that has to do with the interactive spec. See the attached 
next revision, it seems to behave better.

> Then some advice remains unremoved.  Ok, will test more.

I haven't noticed this particular problem, so please write down a repro 
if you find one.

[other-project-prefix-v2.diff (text/x-patch, attachment)]

Message #29 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Thu, 02 May 2024 09:12:18 +0300

>> Something is wrong here.  I bound 'other-project-prefix' to 'C-x p P'.
>> Then typing 'C-x p P C-x d' asked a directory name, then later
>> after selecting a project asked for the directory name again.
>
> Looks like that has to do with the interactive spec. See the attached next
> revision, it seems to behave better.

Thanks, this works now (except that it can't be debugged because of the
Lisp error: (wrong-type-argument listp ignore)).

Also 'C-h' is not a problem: 'help-form-show' does nothing
without 'help-form', but with 'help-form' works fine:

      (define-key map (vector help-char)
                  (lambda ()
                    (interactive)
                    (let ((help-form "You can use any global keybinding."))
                      (help-form-show))))

However, a much bigger problem is that unfortunately many test cases from
https://debbugs.gnu.org/63648#203 are broken.  For example,
'C-x p p C-b' fails the same way as in bug#58784.
'C-x p p f M-n' fails because it expects to read arguments
in a previous project with an old value of default-directory, etc.

Maybe this could be fixed by running 'interactive' in a previous project
by using something like:

  (around-fun
   (lambda (command &rest _args)
     (interactive (lambda (spec)
                    (let ((default-directory prev-dir))
                      (advice-eval-interactive-spec spec))))

Message #32 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sat, 4 May 2024 05:12:39 +0300

[Message part 1 (text/plain, inline)]

On 02/05/2024 09:12, Juri Linkov wrote:
>>> Something is wrong here.  I bound 'other-project-prefix' to 'C-x p P'.
>>> Then typing 'C-x p P C-x d' asked a directory name, then later
>>> after selecting a project asked for the directory name again.
>>
>> Looks like that has to do with the interactive spec. See the attached next
>> revision, it seems to behave better.
> 
> Thanks, this works now (except that it can't be debugged because of the
> Lisp error: (wrong-type-argument listp ignore)).
> 
> Also 'C-h' is not a problem: 'help-form-show' does nothing
> without 'help-form', but with 'help-form' works fine:
> 
>        (define-key map (vector help-char)
>                    (lambda ()
>                      (interactive)
>                      (let ((help-form "You can use any global keybinding."))
>                        (help-form-show))))

We would want 'C-h' to show the regular buffer with key bindings, won't 
we? With similar output to the one that we get after 'C-x p C-h' or 'C-x 
v C-h'. The output might be weirder because of the composed keymap, but 
it could still be useful.

Also, with which-key-mode, C-h would do its thing.

> However, a much bigger problem is that unfortunately many test cases from
> https://debbugs.gnu.org/63648#203 are broken.  For example,
> 'C-x p p C-b' fails the same way as in bug#58784.
> 'C-x p p f M-n' fails because it expects to read arguments
> in a previous project with an old value of default-directory, etc.

Thanks for noticing. Looks like the call to project-prompter can change 
the value of this-command, and that's why the subsequent check went down 
the wrong branch. See the attached v3 with the fix.

> Maybe this could be fixed by running 'interactive' in a previous project
> by using something like:
> 
>    (around-fun
>     (lambda (command &rest _args)
>       (interactive (lambda (spec)
>                      (let ((default-directory prev-dir))
>                        (advice-eval-interactive-spec spec))))

I think the command might rather expect to be called in the "new" 
project. And also while some have interactive specs with significant 
logic inside, others don't; introducing a difference there could cause 
more problems.

[other-project-prefix-v3.diff (text/x-patch, attachment)]

Message #35 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sat, 04 May 2024 10:24:46 +0300

> Cc: 70577 <at> debbugs.gnu.org
> Date: Sat, 4 May 2024 05:12:39 +0300
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> +(defun other-project-prefix ()
> +  "\"Switch\" to another project before running an Emacs command.
> +Makes sure the next command invoked asks for the project to run it in."

This last sentence reads awkwardly and confusingly.  Suggest to reword

  The next command you invoke will prompt for the project in which to
  run the command.

Thanks.

Message #38 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70577 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sat, 4 May 2024 20:22:39 +0300

On 04/05/2024 10:24, Eli Zaretskii wrote:
>> Cc:70577 <at> debbugs.gnu.org
>> Date: Sat, 4 May 2024 05:12:39 +0300
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> +(defun other-project-prefix ()
>> +  "\"Switch\" to another project before running an Emacs command.
>> +Makes sure the next command invoked asks for the project to run it in."
> This last sentence reads awkwardly and confusingly.  Suggest to reword
> 
>    The next command you invoke will prompt for the project in which to
>    run the command.

Thanks, that sounds good.

Some ideas regarding 'C-h' behaving differently from the usual would be 
welcome, too.

Message #41 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sat, 04 May 2024 20:34:47 +0300

> Date: Sat, 4 May 2024 20:22:39 +0300
> Cc: juri <at> linkov.net, 70577 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> Some ideas regarding 'C-h' behaving differently from the usual would be 
> welcome, too.

You mean, what help--append-keystrokes-help does?  For that to work,
C-h should have no binding in the last keymap, AFAIR.

Message #44 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70577 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 5 May 2024 03:02:27 +0300

On 04/05/2024 20:34, Eli Zaretskii wrote:
>> Date: Sat, 4 May 2024 20:22:39 +0300
>> Cc:juri <at> linkov.net,70577 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> Some ideas regarding 'C-h' behaving differently from the usual would be
>> welcome, too.
> You mean, what help--append-keystrokes-help does?  For that to work,
> C-h should have no binding in the last keymap, AFAIR.

As you can see in the attached patches, I don't add a C-h binding to the 
generated map.

And the text (`C-h' for help) does get printed, but pressing this key 
combination doesn't show help. That seems like a problem.

Message #47 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 05 May 2024 08:44:47 +0300

> Date: Sun, 5 May 2024 03:02:27 +0300
> Cc: juri <at> linkov.net, 70577 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 04/05/2024 20:34, Eli Zaretskii wrote:
> >> Date: Sat, 4 May 2024 20:22:39 +0300
> >> Cc:juri <at> linkov.net,70577 <at> debbugs.gnu.org
> >> From: Dmitry Gutov<dmitry <at> gutov.dev>
> >>
> >> Some ideas regarding 'C-h' behaving differently from the usual would be
> >> welcome, too.
> > You mean, what help--append-keystrokes-help does?  For that to work,
> > C-h should have no binding in the last keymap, AFAIR.
> 
> As you can see in the attached patches, I don't add a C-h binding to the 
> generated map.
> 
> And the text (`C-h' for help) does get printed, but pressing this key 
> combination doesn't show help. That seems like a problem.

Can you show a recipe that I could try with the current master to
reproduce this?   Then I could take a look.

Message #50 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 05 May 2024 19:40:14 +0300

> We would want 'C-h' to show the regular buffer with key bindings, won't we?
> With similar output to the one that we get after 'C-x p C-h' or 'C-x
> v C-h'. The output might be weirder because of the composed keymap, but it
> could still be useful.

Then maybe something like

  (define-key map (vector help-char)
              (lambda () (interactive) (describe-bindings)))

or

  (define-key map (vector help-char)
              (lambda () (interactive) (describe-keymap (cons 'keymap (current-active-maps)))))

or

  (define-key map (vector help-char)
              (lambda () (interactive) (describe-keymap (cons 'keymap project-prefix-map))))

>> However, a much bigger problem is that unfortunately many test cases from
>> https://debbugs.gnu.org/63648#203 are broken.  For example,
>> 'C-x p p C-b' fails the same way as in bug#58784.
>> 'C-x p p f M-n' fails because it expects to read arguments
>> in a previous project with an old value of default-directory, etc.
>
> Thanks for noticing. Looks like the call to project-prompter can change the
> value of this-command, and that's why the subsequent check went down the
> wrong branch. See the attached v3 with the fix.

Wow, everything works now, will test more as a primary 'C-x p p' command.

Message #53 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70577 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 5 May 2024 21:26:38 +0300

On 05/05/2024 08:44, Eli Zaretskii wrote:
>> Date: Sun, 5 May 2024 03:02:27 +0300
>> Cc:juri <at> linkov.net,70577 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> On 04/05/2024 20:34, Eli Zaretskii wrote:
>>>> Date: Sat, 4 May 2024 20:22:39 +0300
>>>> Cc:juri <at> linkov.net,70577 <at> debbugs.gnu.org
>>>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>>>
>>>> Some ideas regarding 'C-h' behaving differently from the usual would be
>>>> welcome, too.
>>> You mean, what help--append-keystrokes-help does?  For that to work,
>>> C-h should have no binding in the last keymap, AFAIR.
>> As you can see in the attached patches, I don't add a C-h binding to the
>> generated map.
>>
>> And the text (`C-h' for help) does get printed, but pressing this key
>> combination doesn't show help. That seems like a problem.
> Can you show a recipe that I could try with the current master to
> reproduce this?   Then I could take a look.

Thanks, I've found the problem - it was caused by the specific code in 
the function, not something general (it skipped the invocation of 
COMMAND inside AROUND-FUN).

Message #56 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 5 May 2024 21:55:15 +0300

[Message part 1 (text/plain, inline)]

On 05/05/2024 19:40, Juri Linkov wrote:
>> We would want 'C-h' to show the regular buffer with key bindings, won't we?
>> With similar output to the one that we get after 'C-x p C-h' or 'C-x
>> v C-h'. The output might be weirder because of the composed keymap, but it
>> could still be useful.
> 
> Then maybe something like
> 
>    (define-key map (vector help-char)
>                (lambda () (interactive) (describe-bindings)))
> 
> or
> 
>    (define-key map (vector help-char)
>                (lambda () (interactive) (describe-keymap (cons 'keymap (current-active-maps)))))
> 
> or
> 
>    (define-key map (vector help-char)
>                (lambda () (interactive) (describe-keymap (cons 'keymap project-prefix-map))))

This actually seems unnecessary. See the attached latest version where 
the binding works automatically without explicit assignment.

>>> However, a much bigger problem is that unfortunately many test cases from
>>> https://debbugs.gnu.org/63648#203 are broken.  For example,
>>> 'C-x p p C-b' fails the same way as in bug#58784.
>>> 'C-x p p f M-n' fails because it expects to read arguments
>>> in a previous project with an old value of default-directory, etc.
>>
>> Thanks for noticing. Looks like the call to project-prompter can change the
>> value of this-command, and that's why the subsequent check went down the
>> wrong branch. See the attached v3 with the fix.
> 
> Wow, everything works now, will test more as a primary 'C-x p p' command.

Thanks, let me know if you find any other problems.

[other-project-prefix-v4.diff (text/x-patch, attachment)]

Message #59 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Mon, 06 May 2024 20:25:42 +0300

>> Wow, everything works now, will test more as a primary 'C-x p p' command.
>
> Thanks, let me know if you find any other problems.

I confirm that everything works nicely, thanks.  The only
problem is that after trying to use it, its order looks unnatural.
I already accustomed to this order: 1) select the project,
2) run the command.  This is handy especially with
project-switch-commands set to 'project-prefix-or-any-command'.
This order looks more logical because after selecting the
project, the user mentally switches to another project, and
then types a command with arguments in the switched project.
However, the reverse order of typing a command keys
before switching the project looks like trying
to run the command in the previous project.
Also the problem is that typing a command keys and reading
the command arguments is separated by reading a project.

Maybe many users would prefer other-project-prefix, I don't know.
But other-project-prefix can't replace project-switch-project,
only to be an alternative.

Message #62 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Mon, 06 May 2024 21:30:34 +0300

>>> Wow, everything works now, will test more as a primary 'C-x p p' command.
>>
>> Thanks, let me know if you find any other problems.
>
> I confirm that everything works nicely, thanks.  The only
> problem is that after trying to use it, its order looks unnatural.
> I already accustomed to this order: 1) select the project,
> 2) run the command.  This is handy especially with
> project-switch-commands set to 'project-prefix-or-any-command'.
> This order looks more logical because after selecting the
> project, the user mentally switches to another project, and
> then types a command with arguments in the switched project.
> However, the reverse order of typing a command keys
> before switching the project looks like trying
> to run the command in the previous project.
> Also the problem is that typing a command keys and reading
> the command arguments is separated by reading a project.
>
> Maybe many users would prefer other-project-prefix, I don't know.
> But other-project-prefix can't replace project-switch-project,
> only to be an alternative.

Sorry, I didn't realize that implementation of other-project-prefix
can be changed to read the project before reading the command
with arguments:

  (defun other-project-prefix ()
    (letrec ((root (funcall project-prompter))
             (depth (minibuffer-depth))
             (echofun (lambda () "[switch-project]"))
             (around-fun
              ...

Message #65 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 7 May 2024 22:16:40 +0300

On 06/05/2024 20:25, Juri Linkov wrote:
>>> Wow, everything works now, will test more as a primary 'C-x p p' command.
>>
>> Thanks, let me know if you find any other problems.
> 
> I confirm that everything works nicely, thanks.  The only
> problem is that after trying to use it, its order looks unnatural.
> I already accustomed to this order: 1) select the project,
> 2) run the command.  This is handy especially with
> project-switch-commands set to 'project-prefix-or-any-command'.

Could be a problem indeed, but only if we are aiming at changing the 
default. We're probably not going to do that, or at least not right away.

> This order looks more logical because after selecting the
> project, the user mentally switches to another project, and
> then types a command with arguments in the switched project.
> However, the reverse order of typing a command keys
> before switching the project looks like trying
> to run the command in the previous project.
> Also the problem is that typing a command keys and reading
> the command arguments is separated by reading a project.

My advantage (maybe?) is that I don't use the "switch project" command 
very often. But when I do and I think about it, it kinds of seem to 
stick out compared to some other commands, in particular "prefix" ones, 
that you have two separate key sequences which you need to input, 
instead of just one longer one.

That's where my main motivation for this patch comes (the other being 
that 'C-h' works with it).

Speaking of the implementation strategy, though, I think the current 
other-project-prefix implementation still doesn't work well together 
with project-other-*-command.

I.e. I'd expect 'C-x p P C-x 4 p f' to function as "find file in 
different project", but it both interrupts the key sequence before the 
last char (with a prompt), and ultimately fails to switch to that 
different project.

> Maybe many users would prefer other-project-prefix, I don't know.
> But other-project-prefix can't replace project-switch-project,
> only to be an alternative.

I think we could add the new command, and then revisit the question of 
defaults in 1-2 years. I guess the main difficulty is documenting all 
the new alternatives added in Emacs 30 adequately, so the user can make 
a confident choice which one to use.

Message #68 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 7 May 2024 22:23:53 +0300

On 06/05/2024 21:30, Juri Linkov wrote:
>>>> Wow, everything works now, will test more as a primary 'C-x p p' command.
>>> Thanks, let me know if you find any other problems.
>> I confirm that everything works nicely, thanks.  The only
>> problem is that after trying to use it, its order looks unnatural.
>> I already accustomed to this order: 1) select the project,
>> 2) run the command.  This is handy especially with
>> project-switch-commands set to 'project-prefix-or-any-command'.
>> This order looks more logical because after selecting the
>> project, the user mentally switches to another project, and
>> then types a command with arguments in the switched project.
>> However, the reverse order of typing a command keys
>> before switching the project looks like trying
>> to run the command in the previous project.
>> Also the problem is that typing a command keys and reading
>> the command arguments is separated by reading a project.
>>
>> Maybe many users would prefer other-project-prefix, I don't know.
>> But other-project-prefix can't replace project-switch-project,
>> only to be an alternative.
> Sorry, I didn't realize that implementation of other-project-prefix
> can be changed to read the project before reading the command
> with arguments:
> 
>    (defun other-project-prefix ()
>      (letrec ((root (funcall project-prompter))
>               (depth (minibuffer-depth))
>               (echofun (lambda () "[switch-project]"))
>               (around-fun
>                ...

Yeah, it can be made tweakable like that, although I'd suggest first 
trying to use it as-is for a little bit.

If you prefer to read the project first, would see a lot of advantage to 
the new command? I suppose 'C-h' working is the only plus.

Message #71 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Thu, 9 May 2024 05:22:18 +0300

On 07/05/2024 22:16, Dmitry Gutov wrote:
> Speaking of the implementation strategy, though, I think the current 
> other-project-prefix implementation still doesn't work well together 
> with project-other-*-command.

I suppose we could just blacklist some known prefix commands (*) in the 
same form where we now compare (eq this-command 'other-project-prefix), 
but it would be nice to distinguish prefix commands from "real" ones 
somehow.

(*) project-other-window-command, project-other-frame-command, 
project-other-tab-command, some others?

Message #74 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Thu, 09 May 2024 09:20:29 +0300

>> Speaking of the implementation strategy, though, I think the current
>> other-project-prefix implementation still doesn't work well together with
>> project-other-*-command.
>
> I suppose we could just blacklist some known prefix commands (*) in the
> same form where we now compare (eq this-command 'other-project-prefix), but
> it would be nice to distinguish prefix commands from "real" ones somehow.
>
> (*) project-other-window-command, project-other-frame-command,
> project-other-tab-command, some others?

I remember that other-commands worked in one of your previous patches.

Message #77 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Thu, 09 May 2024 09:24:38 +0300

>> can be changed to read the project before reading the command
>> with arguments:
>>    (defun other-project-prefix ()
>>      (letrec ((root (funcall project-prompter))
>>               (depth (minibuffer-depth))
>>               (echofun (lambda () "[switch-project]"))
>>               (around-fun
>>                ...
>
> Yeah, it can be made tweakable like that, although I'd suggest first trying
> to use it as-is for a little bit.

I tried but still can't use it because its sequence of reading
the project is incompatible with old 'project-switch-project',
so it's difficult to switch to the new sequence.

> If you prefer to read the project first, would see a lot of advantage to
> the new command? I suppose 'C-h' working is the only plus.

The advantage is that the new command paves the way for
implementing the support of 'C-x p P C-x 4 p f'.

Message #80 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Fri, 10 May 2024 04:46:27 +0300

On 09/05/2024 09:20, Juri Linkov wrote:
>>> Speaking of the implementation strategy, though, I think the current
>>> other-project-prefix implementation still doesn't work well together with
>>> project-other-*-command.
>> I suppose we could just blacklist some known prefix commands (*) in the
>> same form where we now compare (eq this-command 'other-project-prefix), but
>> it would be nice to distinguish prefix commands from "real" ones somehow.
>>
>> (*) project-other-window-command, project-other-frame-command,
>> project-other-tab-command, some others?
> I remember that other-commands worked in one of your previous patches.

Maybe only when they went down the

  (if (< emacs-major-version 30)

code path?

Like project-any-command, project--other-place-command uses 
read-key-sequence and then invokes the command, which means that 
whatever dynamic binding was in effect, stays in effect for the "next" 
command.

Conversely, calling project--other-place-prefix ends the current 
command, and the dynamic binding ends there too.

Message #83 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Fri, 10 May 2024 09:43:52 +0300

>>>> Speaking of the implementation strategy, though, I think the current
>>>> other-project-prefix implementation still doesn't work well together with
>>>> project-other-*-command.
>>> I suppose we could just blacklist some known prefix commands (*) in the
>>> same form where we now compare (eq this-command 'other-project-prefix), but
>>> it would be nice to distinguish prefix commands from "real" ones somehow.
>>>
>>> (*) project-other-window-command, project-other-frame-command,
>>> project-other-tab-command, some others?
>> I remember that other-commands worked in one of your previous patches.
>
> Maybe only when they went down the
>
>   (if (< emacs-major-version 30)
>
> code path?

Nope, only 30.  (But it's possible that I mistyped 'C-x p p' instead of 'C-x p P'.)

> Conversely, calling project--other-place-prefix ends the current command,
> and the dynamic binding ends there too.

set-transient-map has the arg KEEP-PRED that could be used to keep the map
for a sequence of commands, but its use might be tricky.

Message #86 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Fri, 10 May 2024 18:09:48 +0300

On 10/05/2024 09:43, Juri Linkov wrote:

>> Conversely, calling project--other-place-prefix ends the current command,
>> and the dynamic binding ends there too.
> set-transient-map has the arg KEEP-PRED that could be used to keep the map
> for a sequence of commands, but its use might be tricky.

I'm not sure if it can help: what we need to do is not keep the keymap, 
but keep the advice from applying too early (meaning, keep the 
pre-command-hook from firing and removing itself before the wrong command).

Message #89 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 12 May 2024 21:33:13 +0300

[Message part 1 (text/plain, inline)]

On 09/05/2024 05:22, Dmitry Gutov wrote:
> On 07/05/2024 22:16, Dmitry Gutov wrote:
>> Speaking of the implementation strategy, though, I think the current 
>> other-project-prefix implementation still doesn't work well together 
>> with project-other-*-command.
> 
> I suppose we could just blacklist some known prefix commands (*) in the 
> same form where we now compare (eq this-command 'other-project-prefix), 
> but it would be nice to distinguish prefix commands from "real" ones 
> somehow.
> 
> (*) project-other-window-command, project-other-frame-command, 
> project-other-tab-command, some others?

This can look like the attached.

Though I suppose we would use some global registry, or symbol 
properties, or etc.

[other-project-prefix-v5.diff (text/x-patch, attachment)]

Message #92 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 14 May 2024 09:23:18 +0300

>>> Speaking of the implementation strategy, though, I think the current
>>> other-project-prefix implementation still doesn't work well together
>>> with project-other-*-command.
>> I suppose we could just blacklist some known prefix commands (*) in the
>> same form where we now compare (eq this-command 'other-project-prefix),
>> but it would be nice to distinguish prefix commands from "real" ones
>> somehow.
>> (*) project-other-window-command, project-other-frame-command,
>> project-other-tab-command, some others?
>
> This can look like the attached.
>
> Though I suppose we would use some global registry, or symbol properties,
> or etc.
>
> +(defvar other-project-prefix-transient-commands '(project-other-window-command
> +                                                  project-other-frame-command
> +                                                  project-other-tab-command
> +                                                  other-window-prefix
> +                                                  other-frame-prefix
> +                                                  other-tab-prefix)
> +  "List of commands that `other-project-prefix' does not apply to.

This doesn't yet support such things as 'C-x 5 p p'?

Message #95 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 14 May 2024 23:02:51 +0300

On 14/05/2024 09:23, Juri Linkov wrote:
>>>> Speaking of the implementation strategy, though, I think the current
>>>> other-project-prefix implementation still doesn't work well together
>>>> with project-other-*-command.
>>> I suppose we could just blacklist some known prefix commands (*) in the
>>> same form where we now compare (eq this-command 'other-project-prefix),
>>> but it would be nice to distinguish prefix commands from "real" ones
>>> somehow.
>>> (*) project-other-window-command, project-other-frame-command,
>>> project-other-tab-command, some others?
>>
>> This can look like the attached.
>>
>> Though I suppose we would use some global registry, or symbol properties,
>> or etc.
>>
>> +(defvar other-project-prefix-transient-commands '(project-other-window-command
>> +                                                  project-other-frame-command
>> +                                                  project-other-tab-command
>> +                                                  other-window-prefix
>> +                                                  other-frame-prefix
>> +                                                  other-tab-prefix)
>> +  "List of commands that `other-project-prefix' does not apply to.
> 
> This doesn't yet support such things as 'C-x 5 p p'?

I'm not sure that other-project-prefix can do that.

How does other-frame-prefix work? display-buffer-override-next-command 
sets up hooks in the very familiar fashion, so that the next command 
(and only the next command) is affected by a number of changed 
variables, which get restored after.

I suppose other-project-prefix could learn all the new variables it 
needs to "carry on", look up their values, and set them additionally for 
the next command. But that seems very ad-hoc.

It seems the "proper" way to fix that would be a cross-codebase change 
where all similar "prefix" commands themselves check whether the next 
command is a "prefix" command as well, and if so, keep the variables and 
hooks in place for the command after it. This would also mean moving the 
information from other-project-prefix-transient-commands to symbol 
properties (the alternative I've mentioned previously).

Message #98 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Wed, 15 May 2024 09:46:52 +0300

>>> +(defvar other-project-prefix-transient-commands '(project-other-window-command
>>> +                                                  project-other-frame-command
>>> +                                                  project-other-tab-command
>>> +                                                  other-window-prefix
>>> +                                                  other-frame-prefix
>>> +                                                  other-tab-prefix)
>>> +  "List of commands that `other-project-prefix' does not apply to.
>> This doesn't yet support such things as 'C-x 5 p p'?
>
> I'm not sure that other-project-prefix can do that.
>
> How does other-frame-prefix work? display-buffer-override-next-command sets
> up hooks in the very familiar fashion, so that the next command (and only
> the next command) is affected by a number of changed variables, which get
> restored after.
>
> I suppose other-project-prefix could learn all the new variables it needs
> to "carry on", look up their values, and set them additionally for the next
> command. But that seems very ad-hoc.
>
> It seems the "proper" way to fix that would be a cross-codebase change
> where all similar "prefix" commands themselves check whether the next
> command is a "prefix" command as well, and if so, keep the variables and
> hooks in place for the command after it. This would also mean moving the
> information from other-project-prefix-transient-commands to symbol
> properties (the alternative I've mentioned previously).

In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#95
I made an unfinished attempt to handle this by:

```
diff --git a/lisp/window.el b/lisp/window.el
index ab7dd5ced12..52ba407d9c8 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -9099,7 +9091,8 @@ display-buffer-override-next-command
 		     (> (minibuffer-depth) minibuffer-depth)
 		     ;; But don't remove immediately after
 		     ;; adding the hook by the same command below.
-		     (eq this-command command))
+		     (eq this-command command)
+		     (memq this-command '(other-project-prefix)))
               (funcall exitfun))))
     ;; Call post-function after the next command finishes (bug#49057).
     (add-hook 'post-command-hook postfun)
```

I'm not sure if this is a proper way, this needs more trial-and-error.

Message #101 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 21 May 2024 05:31:28 +0300

[Message part 1 (text/plain, inline)]

On 15/05/2024 09:46, Juri Linkov wrote:
>>>> +(defvar other-project-prefix-transient-commands '(project-other-window-command
>>>> +                                                  project-other-frame-command
>>>> +                                                  project-other-tab-command
>>>> +                                                  other-window-prefix
>>>> +                                                  other-frame-prefix
>>>> +                                                  other-tab-prefix)
>>>> +  "List of commands that `other-project-prefix' does not apply to.
>>> This doesn't yet support such things as 'C-x 5 p p'?
>>
>> I'm not sure that other-project-prefix can do that.
>>
>> How does other-frame-prefix work? display-buffer-override-next-command sets
>> up hooks in the very familiar fashion, so that the next command (and only
>> the next command) is affected by a number of changed variables, which get
>> restored after.
>>
>> I suppose other-project-prefix could learn all the new variables it needs
>> to "carry on", look up their values, and set them additionally for the next
>> command. But that seems very ad-hoc.
>>
>> It seems the "proper" way to fix that would be a cross-codebase change
>> where all similar "prefix" commands themselves check whether the next
>> command is a "prefix" command as well, and if so, keep the variables and
>> hooks in place for the command after it. This would also mean moving the
>> information from other-project-prefix-transient-commands to symbol
>> properties (the alternative I've mentioned previously).
> 
> In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63648#95
> I made an unfinished attempt to handle this by:
> 
> ```
> diff --git a/lisp/window.el b/lisp/window.el
> index ab7dd5ced12..52ba407d9c8 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -9099,7 +9091,8 @@ display-buffer-override-next-command
>   		     (> (minibuffer-depth) minibuffer-depth)
>   		     ;; But don't remove immediately after
>   		     ;; adding the hook by the same command below.
> -		     (eq this-command command))
> +		     (eq this-command command)
> +		     (memq this-command '(other-project-prefix)))
>                 (funcall exitfun))))
>       ;; Call post-function after the next command finishes (bug#49057).
>       (add-hook 'post-command-hook postfun)
> ```
> 
> I'm not sure if this is a proper way, this needs more trial-and-error.

Looks like you were thinking along similar lines.

Here's a patch using symbol properties that makes the prefix commands 
work combined in arbitrary order. At least according to my limited 
testing - and only the commands that have this property set, of course.

Something to discuss:
- A better name for the property? Maybe something longer would be more 
obvious for an accidental reader.
- Applying it through 'declare' forms could be a more self-contained 
approach.

[other-project-prefix-v6.diff (text/x-patch, attachment)]

Message #104 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 21 May 2024 09:08:20 +0300

> Here's a patch using symbol properties that makes the prefix commands work
> combined in arbitrary order. At least according to my limited testing - and
> only the commands that have this property set, of course.

This works until I moved project-prompter to the beginning,
then 'C-x 5 p p' doesn't work with this:

  (letrec ((root (funcall project-prompter))
           (depth (minibuffer-depth))
           (echofun (lambda () "[switch-project]"))
           (around-fun

Maybe there is a better place?

> Something to discuss:
> - A better name for the property? Maybe something longer would be more
>   obvious for an accidental reader.

If it makes sense to use it outside of project.el
then 'prefix-command' is fine.

> - Applying it through 'declare' forms could be a more self-contained
>   approach.

This could be added later as well.

Message #107 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 21 May 2024 23:16:55 +0300

On 21/05/2024 09:08, Juri Linkov wrote:
>> Here's a patch using symbol properties that makes the prefix commands work
>> combined in arbitrary order. At least according to my limited testing - and
>> only the commands that have this property set, of course.
> 
> This works until I moved project-prompter to the beginning,
> then 'C-x 5 p p' doesn't work with this:
> 
>    (letrec ((root (funcall project-prompter))
>             (depth (minibuffer-depth))
>             (echofun (lambda () "[switch-project]"))
>             (around-fun
> 
> Maybe there is a better place?

Last I checked, the project-prompter can change the value of this-command.

Perhaps you can try a let-binding for this-command around the call to 
project-prompter, so that it's restored at the end.

Something to also be concerned about is having any of the display-buffer 
modifications, or other-project advices, get applied to one of the 
commands inside the project-prompter UI (if it's implemented using a 
sequence of commands). Perhaps I haven't triggered this case mostly by 
luck so far. How to guard against that? Maybe a dynamic variable of some 
sort. But then it'd also have to be checked uniformly in all such 
functions (hooks that prefix commands install).

>> Something to discuss:
>> - A better name for the property? Maybe something longer would be more
>>    obvious for an accidental reader.
> 
> If it makes sense to use it outside of project.el
> then 'prefix-command' is fine.
> 
>> - Applying it through 'declare' forms could be a more self-contained
>>    approach.
> 
> This could be added later as well.

Message #110 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Wed, 22 May 2024 09:12:19 +0300

>> This works until I moved project-prompter to the beginning,
>> then 'C-x 5 p p' doesn't work with this:
>>    (letrec ((root (funcall project-prompter))
>>             (depth (minibuffer-depth))
>>             (echofun (lambda () "[switch-project]"))
>>             (around-fun
>> Maybe there is a better place?
>
> Last I checked, the project-prompter can change the value of this-command.
>
> Perhaps you can try a let-binding for this-command around the call to
> project-prompter, so that it's restored at the end.

This helps: (letrec ((root (let ((this-command this-command)) (funcall project-prompter)))

> Something to also be concerned about is having any of the display-buffer
> modifications, or other-project advices, get applied to one of the commands
> inside the project-prompter UI (if it's implemented using a sequence of
> commands). Perhaps I haven't triggered this case mostly by luck so far. How
> to guard against that? Maybe a dynamic variable of some sort. But then it'd
> also have to be checked uniformly in all such functions (hooks that prefix
> commands install).

This also helps:

diff --git a/lisp/window.el b/lisp/window.el
index 4147d7e6ebb..a4577d509b8 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -9252,7 +9279,7 @@ display-buffer-override-next-command
                        ;; after the first display-buffer action (bug#39722).
                        (funcall clearfun)
                        new-window))))
-         (command this-command)
+         (command this-original-command)
          (echofun (when echo (lambda () echo)))
          (exitfun
           (lambda ()
@@ -9274,7 +9301,8 @@ display-buffer-override-next-command
 		     (> (minibuffer-depth) minibuffer-depth)
 		     ;; But don't remove immediately after
 		     ;; adding the hook by the same command below.
-		     (eq this-command command))
+		     (eq this-original-command command)
+		     (get command 'prefix-command))
               (funcall exitfun))))
     ;; Call post-function after the next command finishes (bug#49057).
     (add-hook 'post-command-hook postfun)

But not sure about the latter, it might break some cases.

Message #113 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Thu, 23 May 2024 09:24:50 +0300

> -		     (eq this-command command))
> +		     (eq this-original-command command)

Actually the real problem is that in project--other-place-prefix
prefix-command-preserve-state changes this-command to last-command.

Message #116 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 26 May 2024 05:38:33 +0300

On 23/05/2024 09:24, Juri Linkov wrote:
>> -		     (eq this-command command))
>> +		     (eq this-original-command command)
> Actually the real problem is that in project--other-place-prefix
> prefix-command-preserve-state changes this-command to last-command.

This one might not be so bad (the idea, as documented, seems sensible).

Changing this-read-command seems more suspect.

But I guess it really means more checks would need to be done on 
this-original-command instead. :-/

The (eq this-original-command command) check could probably be dropped, 
but otherwise your addition looks good (I don't know any cases where 
this-original-command would be wrong, though apparently there might be 
some -- remappings of the prefix commands? seems an odd thing to do).

It might also be possible to rewrite 
display-buffer-override-next-command in a way that the installation of 
the "advice" (not actual advice in its case) happens in pre-command-hook 
- then at that point the current command hasn't had a chance to alter 
this-command.

prefun would check whether it needs to be applied, if yet, add the 
cleanup function to post-command-hook, and run the setup. The 
modification of display-buffer-overriding-action might also be better 
done there, so it doesn't alter any prompter UI in the next prefix 
command that might be invoked.

Not an urgent change, just something to consider.

Have you had a chance to run with the modified patch a little? Any edge 
new edge cases crop up?

Message #119 received at 70577 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70577 <at> debbugs.gnu.org
Subject: Re: bug#70577: [PATCH] New command other-project-prefix
Date: Sun, 26 May 2024 09:52:37 +0300

>>> -		     (eq this-command command))
>>> +		     (eq this-original-command command)
>> Actually the real problem is that in project--other-place-prefix
>> prefix-command-preserve-state changes this-command to last-command.
>
> This one might not be so bad (the idea, as documented, seems sensible).
>
> Changing this-read-command seems more suspect.
>
> But I guess it really means more checks would need to be done on
> this-original-command instead. :-/
>
> The (eq this-original-command command) check could probably be dropped, but
> otherwise your addition looks good (I don't know any cases where
> this-original-command would be wrong, though apparently there might be some
> -- remappings of the prefix commands? seems an odd thing to do).
>
> It might also be possible to rewrite display-buffer-override-next-command
> in a way that the installation of the "advice" (not actual advice in its
> case) happens in pre-command-hook - then at that point the current command
> hasn't had a chance to alter this-command.
>
> prefun would check whether it needs to be applied, if yet, add the cleanup
> function to post-command-hook, and run the setup. The modification of
> display-buffer-overriding-action might also be better done there, so it
> doesn't alter any prompter UI in the next prefix command that might be
> invoked.
>
> Not an urgent change, just something to consider.
>
> Have you had a chance to run with the modified patch a little? Any edge new
> edge cases crop up?

I tried to use the patch for a while, with and without this-original-command,
but it often leaves the postfun hook in display-buffer-override-next-command
active infinitely, thus needed to restart Emacs too often, so I just
removed the patch without debugging what part causes this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.