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

[Dmitry Gutov]

On 20/09/2023 20:10, 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.
>
> Or vice versa.

Yes.

> > > > 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.
>
> With other-project-prefix, users can run 'project-find-file'
> in another project with just:
>
> ```
> (defun other-project-find-file ()
>    (interactive)
>    (call-interactively 'other-project-prefix)
>    (call-interactively 'project-find-file))
> ```

Right... but they'd have to define a custom function for any such 
command. I think the idea behind 'other-project-prefix' is that one 
wouldn't have to.

> > > > 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).
>
> No problem, project-switch-use-entire-map can be easily supported in
> other-project-prefix.

I'm not saying it's hard to support it there. But it could make the 
command less useful.

> > 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.
>
> Agreed, a better prompt needed.  Maybe with the standard C-h key for help.

Some short version initially, and perhaps a more expanded if the user 
hits 'C-h'.

> > 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.
>
> Maybe this short menu is not much needed.  OTOH, it doesn't cause distraction.

I think some menu, or an explanation, anything, is better than nothing.

> > > > 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?
>
> Then for repeating the previously selected project it will be in the history:
> 'C-x p p M-p'.

Fair point. Still, that's more typing and required one to remember/know 
about M-p.

> > 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.
>
> Like it does when typed e.g. 'C-x p f' in a non-project directory?

Yep.

> > > 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.
>
> And also other-project-prefix will fix such bugs as bug#65558.
>
> > Would it add shortcuts to the commands from the project keymap?
> > Possibly. Any ideas how to inform the user about that?
>
> By a different prompt?

Probably. Would you like to propose one? So that I have something to 
compare to, and have something specific to put to the vote as well.