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

[Juri Linkov]

>>> - Unfortunately, using default-directory instead of the specialized
>>>    variable which we added lately (project-current-directory-override)
>>>    brings back the bug it was added for: https://debbugs.gnu.org/58784. The
>>>    switch to a different design didn't fix the problem of the temporary
>>>    binding for d-d in the buffer which is current when the command is
>>>    executed. So adding the next-default-directory variable might not be the
>>>    best idea after all. But the advice thingy can set a binding for any
>>>    variable, including the *-override one.
>> I didn't test yet the cases from bug#58784.  So this might require more
>> changes.
>
> We tried to make the default-directory binding work with a couple of
> different changes - it didn't work out.

The problem is that let-binding overrides the buffer-local value:

```
(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'.

>>> - I also managed to get into some transient state where some chars were
>>>    doing one thing (their usual bindings), and some - invoked project
>>>    commands instead, with no apparent method of quitting that state. Maybe
>>>    I'll document it next time I see it.
>> It would be nice to have a reproducible test case.
>> But indeed chars in the project map invoke the project commands,
>> and all other chars fall back to local/global keybindings.
>> 
>>> - Using (project--keymap-prompt) for just a message call is cute, but
>>>    I personally like the "guardrails": if I accidentally type a wrong char
>>>    when choosing the command, I won't have to choose the other project
>>>    again. This is debatable, but both modes of operation are probably worth
>>>    keeping available (opinions welcome).
>> This is easy to do with something like in 'y-or-n-p-map'.
>
> With setting that (or similar) keymap as a transient keymap?

Something like this.

>>> - Either way, with method with the advice should be useful for other
>>>    things, like project--other-place-command.
>> It's not recommended to use advice in the core packages,
>> maybe only for providing backward-compatibility with older versions.
>
> Sure, but it should also be permissible when there is no other way to do
> a thing.
>
> OTOH, if we're talking about new features in core, we could have
> a next-command-variables-alist, where we'd bind any variables that we would
> want.

Such generalization could be added later.

> A general question regarding this approach, for me, is: is a "prefix
> command" a real command?

It's a real command that prepares some transient values for the next command.
Most existing prefix commands have no problems because they modify global
values.  But 'default-directory' is the first buffer-local variable
used for the next command, therefore it requires special-handling.
Too bad that 'default-directory' is not a function.

> And would they "swallow" these prepared variable bindings too early?

The scope of the modified variable depends on concrete needs.
For example, set-transient-map restores its old value in pre-command-hook,
but display-buffer-override-next-command does this in post-command-hook.