GNU bug report logs - #63648
29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 63648 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands
Date: Mon, 18 Sep 2023 16:56:58 +0300

On 18/09/2023 14:00, Dmitry Gutov wrote:
> On 18/09/2023 09:51, Juri Linkov wrote:
>>>> 'C-x p p C-x v L' to see a vc log in another project, and
>>>> 'C-x p p C-x v d' to open vc-dir, etc.
>>> All right, so we also want to support non-project commands. And you 
>>> wanted
>>> to use a common approach for both.
>>>
>>> What if we handle them differently, though? For "project" commands 
>>> (those
>>> that internally call project-current) we can set one variable, and 
>>> for the
>>> rest -- alter default-directory. Then restore the previous value in
>>> post-command.
>>>
>>> The detection of "project commands" could work like this:
>>>
>>> - Is it in one of the special maps? E.g. in project-prefix-map. Or maybe
>>>    it's in project-switch-commands.
>>> - Does the function name start with 'project-'?
>>> - Finally, for user-defined commands we could also introduce a property
>>>    'project-command-p', although the distinction between using
>>>    project-current-directory-override vs default-directory will not be
>>>    important for every such command, so maybe being this thorough is 
>>> not too
>>>   important.
>> Sorry, I don't understand how 'C-x p p' could read the user's mind
>> whether the user afterwards will type a key for a project command
>> or a non-project command?  And depending on user's intention will
>> either set project-current-directory-override or default-directory.
> 
> Ah, I forgot that in the general case we don't read the sequence, find 
> the command and do the thing. We leave the event loop up to Emacs.
> 
> What about pre-command-hook? this-command will already be set by then.

And we should consider whether other-project-prefix should entirely 
subsume project-switch-project. Or they should remain separate commands.

E.g. would people who customized project-switch-commands to a symbol be 
okay with not being able to use the other functionality of 
other-project-prefix?

Or what about the variable project-switch-use-entire-map? I'm not sure 
about dropping it, at least without notifying about that in the UI somehow.

Finally, the current patch drops the loop, so if the user types the 
wrong key, they will need to repeat the command and choose the project 
again.

So perhaps the simplest incremental change is to add 
other-project-prefix which will work with "regular" commands and keep 
project-switch-project for project commands (whether it will support 
"project" commands as well, can be optional).

The downside is that it will require a different key binding (or for the 
user to redefine the current one), so I'm open to discussing all the 
questions above.

Previous Next

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