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

[Dmitry Gutov <dmitry@gutov.dev>]

On 01/09/2023 09:46, Juri Linkov wrote:
>>> (let ((default-directory "/tmp/"))
>>>     (list default-directory
>>>           (buffer-local-value 'default-directory (current-buffer))))
>>> => ("/tmp/""/tmp/")
>>> Here is the shortest test case: 'C-x p p C-b' shows buffers
>>> from two projects when using let-binding for default-directory,
>>> because 'project-buffers' relies on
>>>     (buffer-local-value 'default-directory buf)
>>> This could be fixed by adding special-handling of the default-directory
>>> for the current buffer in 'project-buffers'.
>> What kind of special handling? The "real" buffer-local value is hidden
>> until the "let" exists, the global value is nil, and if the buffer is not
>> a file-visiting one, there is no other file name to test against.
> Additional buffer-local variable like 'buffer-default-directory' could help.
> Or additional global variable 'global-default-directory'.  Or even
> using the global value of the existing variable 'default-directory'.

What code would use it instead of the local value of default-directory? 
Only project-related code? Or other code as well? If it's the former, we 
have an existing variable in the project package. If the latter, we'd 
need some formal description of those usage rules to proceed.

>> Finally, whatever special handling we invent, would have to be mirrored by
>> all subsequent new commands (built-in and third-party) which look up the
>> value of default-directory. Especially project-related ones. How to
>> popularize that knowledge, would be the next question for whatever solution
>> we invent.
> Hopefully there should be not much trouble such as in 'project-buffers'.

I think there exists a class of commands (existing and potential ones) 
that would use default-directory with exact same purpose and expectations.