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

[Dmitry Gutov <dmitry@gutov.dev>]

On 23/11/2023 17:21, Sean Whitton wrote:

>> On 14/11/2023 15:13, Sean Whitton wrote:
>>> X-debbugs-cc: dmitry@gutov.dev, juri@linkov.net, sbaugh@catern.com
>>> Hello,
>>> 1. cd /home/spwhitton/src/some-project && emacs -q
>>> 2. (setopt project-switch-commands #'project-prefix-or-any-command)
>>> 3. (project-remember-project (project-current nil "/home/spwhitton/src/emacs/trunk/))
>>> 4. C-x p p /home/spwhitton/src/emacs/trunk RET C-x v L
>>> VC prints the log of /home/spwhitton/some-project, not that of
>>> /home/spwhitton/src/emacs/trunk.
>>
>> I'm having difficulty reproducing this.
> 
> Hmm.  I can't reproduce it with 'emacs -q', but I can still reproduce
> with my init.el.  I'm not sure whether something changed or whether I
> was wrong before.
> 
>> On step 4, I'm asked for the project root (because *scratch* doesn't
>> have a current VC backend), but the input defaults to the directory
>> chosen in steps 3 and 4. And if I open a file-visiting buffer first,
>> then the prompt is skipped, [...]
> 
> If I select *Messages*, which has a default-directory of "~/", then
> 'C-x p p RET ~/src/emacs/trunk RET C-x v L' prompts me for a directory,
> but the default value is "~/".  Before I start bisecting my init, does
> anything else occur to you?

That's the thing: I've tried a few different things which could have 
helped reproduce this, but they didn't.

> As an aside, it doesn't seem good that whether or not step four prompts
> you for a directory depends on whether the current buffer happens to be
> visiting a file or not.  Can we improve that, or is it inherent to the
> design of the new feature?

More like it's inherent to how the command you are calling is designed: 
it checks for the backend of the current buffer and behaves differently 
depending on whether one is found.

Since project-prefix-or-any-command works in the current buffer, it 
cannot really reset every such local variable. OTOH, it could 
temporarily switch to an empty buffer. In that case, however, any 
thing-at-point functionality won't work (and the invoked command might 
want to use the symbol at point as some default input or etc). At the 
time we discussed this, the latter seemed like a bigger problem.

Like Juri said, this particular disparity can be configured away, but 
different oddities in that class are bound to come up again.