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

[Dmitry Gutov <dmitry@gutov.dev>]

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.