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

[Dmitry Gutov]

On 19/09/2023 20:57, Juri Linkov wrote:
> > And we should consider whether other-project-prefix should entirely subsume
> > project-switch-project. Or they should remain separate commands.
>
> We could leave project-switch-project unobsoleted indefinitely
> for users who might prefer it, and users can bind it to C-x p p.

Or we keep the easier-to-use command on 'C-x p p', and the more 
experienced users would rebind that to 'other-project-prefix', when they 
learn how to use it.

> > E.g. would people who customized project-switch-commands to a symbol be
> > okay with not being able to use the other functionality of
> > other-project-prefix?
>
> Symbolic project-switch-commands is supported by other-project-prefix.

Yes, and that could be a problem: if I as a user want 'C-x p p' to 
always run 'project-find-file', for example (in the other project), but 
I also want to be able to sometimes call 'M-x other-project-prefix' (or 
use a custom binding) to run an arbitrary command in the other project.

> > Or what about the variable project-switch-use-entire-map? I'm not sure
> > about dropping it, at least without notifying about that in the UI somehow.
>
> project-switch-use-entire-map could be handled in other-project-prefix.
> But is this really needed?  I can't imagine why anyone might want
> to disable keys from project-prefix-map.

I think if project-switch-use-entire-map is still wanted, we should just 
keep these commands separate (the same logic as in the previous paragraph).

Why not remove that option? Consider the current UI (which looks almost 
the same in your latest patch): user types 'C-x p p', chooses the 
project and then sees the prompt which only offers the options from 
project-switch-commands. They are not informed that any other keys could 
be used too. So if we were to change the default behavior, I think this 
UI/prompt needs to change, at the very least.

Do we want to drop the whole "choose a command from the list" thing? 
Will that be an improvement overall, for most users? If you think so, I 
suppose we should make a poll somewhere.

> > Finally, the current patch drops the loop, so if the user types the wrong
> > key, they will need to repeat the command and choose the project again.
>
> Indeed, the loop now is the command loop, and maybe it's possible to
> write a hack to set a catch-all in set-transient-map that is not
> finished until a key in the map is typed.  But as with any command,
> if the user types a wrong key sequence, then need to type it again.
> I do this all the time with mistakenly typed keys.  I don't see why
> project keys are the exception.

Maybe because in the middle of it all you have interacted with Emacs to 
choose the other project, and that can be a significant amount of typing?

I suppose, if it worked the other way (first choose the command, and 
then the project), it would make more sense to not care about having the 
user repeat the command sequence.

> > So perhaps the simplest incremental change is to add other-project-prefix
> > which will work with "regular" commands and keep project-switch-project for
> > project commands (whether it will support "project" commands as well, can
> > be optional).
> >
> > The downside is that it will require a different key binding (or for the
> > user to redefine the current one), so I'm open to discussing all the
> > questions above.
>
> A different key binding for the commands that do the same thing?
> Only because the new command uses the command loop?

project-switch-project would continue to show the menu with commands, 
only work with them by default, and obey project-switch-use-entire-map, 
which, when set to t, would enable other commands from the project 
keymap, but only them. All accessible via one character binding. And 
when project-switch-commands is set to a symbol, it would only invoke 
that one command without additional prompting.

other-project-prefix would accept all commands but require full key 
sequence for the invoked command. Would it add shortcuts to the commands 
from the project keymap? Possibly. Any ideas how to inform the user 
about that?