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

[Dmitry Gutov]

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?