From: Juri Linkov <juri@linkov.net>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Spencer Baugh <sbaugh@janestreet.com>,
63648@debbugs.gnu.org, sbaugh@catern.com
Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands
Date: Wed, 20 Sep 2023 20:10:46 +0300 [thread overview]
Message-ID: <86edishisp.fsf@mail.linkov.net> (raw)
In-Reply-To: <f07e09ce-9018-e24f-b4a6-a8e30512b496@gutov.dev> (Dmitry Gutov's message of "Wed, 20 Sep 2023 03:39:08 +0300")
>>> 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.
>>> 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))
```
>>> 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.
> 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.
> 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.
>>> 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'.
> 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?
>>> 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.
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?
next prev parent reply other threads:[~2023-09-20 17:10 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 16:27 bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands Spencer Baugh
2023-05-22 17:51 ` Juri Linkov
2023-05-24 1:14 ` Dmitry Gutov
2023-05-24 6:20 ` Juri Linkov
2023-05-24 15:46 ` Dmitry Gutov
2023-05-24 16:20 ` Juri Linkov
2023-05-24 17:37 ` Juri Linkov
2023-05-24 17:44 ` Juri Linkov
2023-06-01 16:05 ` Juri Linkov
2023-06-02 1:40 ` Dmitry Gutov
2023-06-02 6:40 ` Juri Linkov
2023-06-03 1:30 ` Dmitry Gutov
2023-08-10 11:56 ` sbaugh
2023-08-23 13:53 ` Spencer Baugh
2023-08-23 17:54 ` Juri Linkov
2023-08-29 20:36 ` Spencer Baugh
2023-08-29 20:40 ` Dmitry Gutov
2023-08-29 21:47 ` Spencer Baugh
2023-08-29 22:32 ` Dmitry Gutov
2023-08-30 16:27 ` Juri Linkov
2023-08-31 2:01 ` Dmitry Gutov
2023-08-31 6:47 ` Juri Linkov
2023-08-31 11:13 ` Dmitry Gutov
2023-08-31 16:36 ` Juri Linkov
2023-09-01 1:11 ` Dmitry Gutov
2023-09-01 6:46 ` Juri Linkov
2023-09-01 9:53 ` Dmitry Gutov
2023-09-01 15:59 ` Spencer Baugh
2023-09-02 1:47 ` Dmitry Gutov
2023-09-03 17:11 ` Juri Linkov
2023-09-11 20:16 ` Spencer Baugh
2023-09-12 6:55 ` Juri Linkov
2023-09-10 15:30 ` Juri Linkov
2023-09-12 23:47 ` Dmitry Gutov
2023-09-13 6:47 ` Juri Linkov
2023-09-18 0:12 ` Dmitry Gutov
2023-09-18 6:51 ` Juri Linkov
2023-09-18 11:00 ` Dmitry Gutov
2023-09-18 13:56 ` Dmitry Gutov
2023-09-19 17:57 ` Juri Linkov
2023-09-20 0:39 ` Dmitry Gutov
2023-09-20 17:10 ` Juri Linkov [this message]
2023-09-21 1:16 ` Dmitry Gutov
2023-09-21 6:58 ` Juri Linkov
2023-09-22 15:52 ` Juri Linkov
2023-10-19 0:42 ` Dmitry Gutov
2023-10-19 4:46 ` Eli Zaretskii
2023-10-19 6:43 ` Juri Linkov
2023-10-19 7:51 ` Eli Zaretskii
2023-10-19 9:46 ` Dmitry Gutov
2023-10-19 11:05 ` Eli Zaretskii
2023-10-19 11:34 ` Dmitry Gutov
2023-10-19 12:22 ` sbaugh
2023-10-19 12:49 ` Dmitry Gutov
2023-10-19 14:00 ` Spencer Baugh
2023-10-19 17:17 ` Dmitry Gutov
2023-10-19 19:30 ` Spencer Baugh
2023-10-19 23:25 ` Dmitry Gutov
2023-10-21 16:09 ` Spencer Baugh
2023-10-21 18:43 ` Dmitry Gutov
2023-10-19 18:03 ` Juri Linkov
2023-10-19 19:38 ` Spencer Baugh
2023-10-19 17:56 ` Juri Linkov
2023-10-19 22:39 ` Dmitry Gutov
2023-10-20 6:44 ` Juri Linkov
2023-10-20 19:25 ` Dmitry Gutov
2023-10-23 6:58 ` Juri Linkov
2023-10-23 17:24 ` Dmitry Gutov
2023-10-23 17:34 ` Juri Linkov
2023-10-23 17:36 ` Dmitry Gutov
2023-10-23 18:42 ` Juri Linkov
2023-10-23 18:49 ` Dmitry Gutov
2023-10-25 16:53 ` Juri Linkov
2023-10-25 22:26 ` Dmitry Gutov
2023-10-27 6:50 ` Juri Linkov
2023-10-27 9:38 ` Dmitry Gutov
2023-10-28 16:56 ` Juri Linkov
2023-11-01 21:12 ` Dmitry Gutov
2023-11-02 17:20 ` Juri Linkov
2023-11-02 21:33 ` Dmitry Gutov
2023-11-04 17:28 ` Juri Linkov
2023-11-05 0:55 ` Dmitry Gutov
2023-11-06 7:16 ` Juri Linkov
2023-11-06 22:49 ` Dmitry Gutov
2023-10-21 13:27 ` sbaugh
2023-10-21 18:41 ` Dmitry Gutov
2023-10-21 13:14 ` sbaugh
2023-08-28 22:44 ` Dmitry Gutov
2023-08-29 20:34 ` Spencer Baugh
2023-06-02 12:46 ` Eli Zaretskii
2023-06-02 16:09 ` Juri Linkov
2023-06-02 6:32 ` Eli Zaretskii
2023-06-02 6:55 ` Juri Linkov
2023-06-02 11:39 ` Eli Zaretskii
2023-06-02 16:11 ` Juri Linkov
2023-06-05 6:53 ` Juri Linkov
2023-06-02 17:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-05 6:50 ` Juri Linkov
2023-06-05 14:44 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-05 16:31 ` Juri Linkov
2023-05-24 14:55 ` Spencer Baugh
2023-05-24 16:24 ` Juri Linkov
2023-05-26 15:16 ` Spencer Baugh
2023-05-30 17:48 ` Juri Linkov
2023-06-01 20:31 ` Spencer Baugh
2023-06-01 21:09 ` Drew Adams
2023-06-02 6:33 ` Eli Zaretskii
2023-06-02 6:46 ` Juri Linkov
2023-08-10 11:52 ` sbaugh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86edishisp.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=63648@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=sbaugh@catern.com \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).