bug#67171: 30.0.50; (At least) some VC commands fail with project-prefix-or-any-command

[Sean Whitton]

Hello,

On Wed 06 Dec 2023 at 02:26am +02, Dmitry Gutov wrote:

> On 06/12/2023 00:40, Sean Whitton wrote:
>> Alright, I've bisected it.  After step 3, additionally eval this form:
>>      (define-key project-prefix-map "L" #'vc-print-root-log)
>> I have this because I want to be able to type just L instead of C-x v L.
>> That doesn't work -- possibly not a bug -- but surely adding that
>> binding shouldn't affect C-x v L, at least?
>
> All right, the full scenario is unexpected, but otherwise it's a documented
> behavior, see the docstring for 'project-any-command'.

Thanks, I see what you mean.

> We discussed the possibility of the override in the other way (in
> bug#63648, which resulted in this command), but not an opt-out for
> commands in project-prefix-map, yet.
>
> So... something like this?
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index a81bb63fba4..feef7ba5248 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -1861,9 +1861,10 @@ project-any-command
>      (when command
>        ;; We could also check the command name against "\\`project-",
>        ;; and/or (get command 'project-command).
> -      (map-keymap
> -       (lambda (_evt cmd) (if (eq cmd command) (setq found t)))
> -       project-prefix-map)
> +      (unless (get command 'project-switch-with-default-directory)
> +        (map-keymap
> +         (lambda (_evt cmd) (if (eq cmd command) (setq found t)))
> +         project-prefix-map))
>        (if found
>            (let ((project-current-directory-override root))
>              (call-interactively command))
>
>
> Combined with
>
>   (put 'vc-print-root-log 'project-switch-with-default-directory t)
>
> somewhere in your init script.
>
> The alternative would be tagging all project-related commands. Even if we also
> check for the 'project-' prefix in command's name, the user-defined commands
> using the project API will be affected (I don't know for how many it would be
> a problem, but still).

This solution makes sense.  We definitely want the user to have a way to
tag additional commands.  But couldn't we pre-tag some, like this one,
for example?  It is difficult to think of wanting to not have this one
tagged.  And the user could always remove the tag in their init.

-- 
Sean Whitton