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

[Spencer Baugh <sbaugh@janestreet.com>]

sbaugh@catern.com writes:
> Juri Linkov <juri@linkov.net> writes:
>
>>>>>> 1. the current buffer should remain the same for the next command;
>>>>>> 2. the buffer-local value of 'default-directory' should remain the same;
>>>>>> 3. the next command should have a new value of 'default-directory'.
>>>>>>
>>>>>> I see no way to satisfy all these requirements.
>>>>>
>>>>> Except adding a variable like 'project-current-directory-override'
>>>>> somewhere inside 'command_loop_1'.
>>>> And indeed with the following patch replacing the current definition of
>>>> 'project-switch-project' with just:
>>>>    (defun project-switch-project (dir)
>>>>      (interactive (list (funcall project-prompter)))
>>>>      (setq next-default-directory dir))
>>>
>>> Note that we'd need to keep the previous implementation for a number of
>>> years anyway, to retain compatibility with older emacsen.
>>
>> Then some version-depending condition could be added.
>>
>>>> 'C-x p p (select project ...) RET M-& pwd RET' confirms that
>>>> the command runs in the selected project directory.
>>>> Whereas the original buffer keeps its previous buffer-local value
>>>> of 'default-directory'.
>>>
>>> I suggest you bring up this feature addition on emacs-devel, or otherwise
>>> wait for a review from Eli, at least.
>>>
>>> It's not a big addition, but it's a distinct new feature (the
>>> next-default-directory var).
>>
>> Indeed, such code addition better to be discussed on emacs-devel.
>
> Did this end up being discussed on emacs-devel?  I am still quite
> interested in this feature.

Oh, another thought (which maybe should be discussed on emacs-devel):
maybe we don't need to make this specific next-default-directory var.

Instead, maybe what we want is a way to bind a dynamic variable
*without* changing the buffer-local value.  It would shadow the existing
binding, but if we explicitly switched buffer we'd get back to the old
value.  So we'd have:

(special-let ((default-directory newval))
  (assert default-directory newval))

and

(special-let ((default-directory newval))
  (set-buffer (current-buffer))
  (assert default-directory oldval))

Ignore any complexities of implementing this and any complexities of the
semantics which I haven't covered.  If we had this, would it work as an
alternative to next-default-directory?