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

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

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: Re: bug#63648: 29.0.90; project.el: with switch-use-entire-map,
 switch-project errors on non-project commands
Date: Mon, 18 Sep 2023 03:12:08 +0300

Sorry about the wait.

On 13/09/2023 09:47, Juri Linkov wrote:
>>> So here is a complete tested patch that maintains backward-compatibility
>>> with older versions, and is localized to project.el without the need to
>>> discuss more fundamental changes on emacs-devel, and handles 100% of
>>> known cases such as reported in bug#58784, bug#63829, etc.
>> It sounds like a possibly concise solution, but I'm still wrapping my head
>> around it.
>>
>>> +(make-obsolete-variable
>>> + 'project-current-directory-override
>>> + 'project-current-directory-old
>>> + "30.1")
>> Aren't those variables sufficiently different that making one an alias for
>> another would confuse things?
> Indeed, during development I mistakenly made one an alias for another
> with 'define-obsolete-variable-alias', and this broke both variables.
> So I replaced it with 'make-obsolete-variable' that doesn't make an alias.
> It just designates it as obsolete to show the intention to remove it
> in later versions.

I suppose that would make us liable to support it for a version or two?

>>> +      (setq-local project-current-directory-old default-directory)
>>> +      (setq-local default-directory dir)
>> Could you explain: if we can just set these here and then clean up in
>> postfun, couldn't we likewise set (and then later clean up) the value of
>> project-current-directory-override?
> We need to set 'default-directory' to support non-project commands.
> I already started to use this feature, and it becomes indispensable.
> For example, the most often used commands are vc commands such as
> '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.

Previous Next

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