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 31/08/2023 09:47, Juri Linkov wrote:
>> I've tried the patch a little bit, some more impressions:
>>
>> - 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.

>> - 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?

>> - 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.

A general question regarding this approach, for me, is: is a "prefix 
command" a real command? And would they "swallow" these prepared 
variable bindings too early?