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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 63648 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands
Date: Thu, 21 Sep 2023 04:16:32 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.