From: Dmitry Gutov <dmitry@gutov.dev>
To: sbaugh@catern.com
Cc: Spencer Baugh <sbaugh@janestreet.com>,
63648@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands
Date: Thu, 19 Oct 2023 15:49:20 +0300 [thread overview]
Message-ID: <6149d7a4-f47e-2ac4-91cf-fe144d1a4c63@gutov.dev> (raw)
In-Reply-To: <87r0lqu7ho.fsf@catern.com>
On 19/10/2023 15:22, sbaugh@catern.com wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>> Hi Juri,
>>
>> On 22/09/2023 18:52, Juri Linkov wrote:
>>>>> 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.
>>>>
>>>> Ok, something like this:
>>> Here is a more tested patch. It supports these cases:
>>> (setq project-switch-use-entire-map t)
>>> C-x p p C-b - should not include current buffer in the list of
>>> another project (bug#58784)
>>> C-x p p f M-n - should fetch the right default file name (bug#58784, bug#63829)
>>> C-u C-x p p f emoji TAB - should include ignored emoji-labels.el (bug#63648)
>>> C-x p p C-x d - should visit another project's root (bug#63648)
>>> The same with frames:
>>> C-x 5 p p C-b
>>> C-x 5 p p f M-n
>>> C-u C-x 5 p p f emoji TAB - should not show completions in another frame (bug#65558)
>>> C-x 5 p p C-x d
>>
>> Thank you. Especially for the list.
>>
>> But I think we still haven't reached a decision whether the "loop
>> until correct key is pressed" behavior is useful.
>>
>> I tried to think how to fit the above requirements into the existing
>> model, and it seems to require a new command, and an additional key
>> being pressed sometimes, for explicitness.
>>
>> The attached patch also includes your fix for bug#65558, which seems
>> orthogonal to our dilemma, and could probably be installed
>> separately. It could be dry-ed up a little, though.
>>
>> Anyway, with the attached counter-proposal, the list looks like this:
>>
>> C-x p p C-b - works when project-switch-use-entire-map=t
>> C-x p p f M-n - always works
>> C-u C-x p p f - same
>> C-x p p C-x d - the key sequence is 'C-x p p o C-x d'
>>
>> With frames:
>>
>> C-x 5 p p C-b - works when project-switch-use-entire-map=t
>> C-x 5 p p f M-n - always works
>> C-u C-x 5 p p f emoji TAB - same (thanks to your fix, included)
>> C-x 5 p p C-x d - the key sequence is 'C-x 5 C-x p p o C-x d'
>>
>> The user could add project-list-buffers (or project-switch-to-buffer)
>> to project-switch-commands, though, and then
>> project-switch-use-entire-map won't be needed. Either way's fine.
>>
>> To sum up, that does require pressing an extra key to use commands
>> outside of project-prefix-map, but OTOH that key is shown right in the
>> commands menu. And one doesn't have to (setq
>> project-switch-use-entire-map t) to use it, though that doesn't hurt
>> either.
>>
>> And the meaning of project-switch-use-entire-map remains as it
>> currently is: expand the set of keys to the whole project-prefix-map,
>> but not to all local and global ones.
>>
>> WDYT?
>
> Hm, I personally think having to hit the extra "o" is undesirable. I'm
> not sure whether "C-x p p o" would be an improvement over the current
> state of the world: you can already hit "C-x p p D" to run
> project-dired, so you end up in dired at the root of the project, and
> then run whatever command you like with default-directory=project-root.
It makes this capability apparent, and it's still one fewer keystroke
(and 'o' is close to 'p', too).
> The main downside of C-x p p D is that it necessarily switches buffers,
> which I often don't want. Solving that would be nice, but it would be
> nice to also get a shorter keybinding out of it.
>
> Actually, this gives me an idea. What if we embraced having C-x p p
> switch buffers? What if we had a new command which jumps you to some
> new "project status buffer", whose default-directory=project-root, and
> which has single-letter bindings for the current project-prefix
> commands? Similar to vc-dir. We could probably find some useful
> information to display in that buffer, too, like a header which extracts
> the status from the project's compilation buffer, or a list of the
> buffers in the project.
I'm totally on board with adding such command, except I'm not sure if we
will give away the 'C-x p p' binding to it. But as far as calling the
"next" command, both project-vc-dir and project-dired currently satisfy
your condition, right?
> If we replaced C-x p p with this command, then that would avoid all our
> issues with default-directory and command loops and so on, by just
> biting the bullet and switching buffers.
Except when one wants to call a command that takes the current buffer
into account. And/or its contents in particular (e.g. file name at point).
> Although, maybe we can get the best of both worlds by having C-x p p
> just temporarily switch buffer? It can do (with-current-buffer
> (project-status) ...) plus resolving keybindings as if they were typed
> in the project-status buffer. That seems pretty elegant to me and
> resolves a lot of complexities without giving up anything.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63829 was a problem caused
by a similar approach in the implementation. OTOH,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58784 probably doesn't
apply (most of the time; unless the projects are nested or whatever).
next prev parent reply other threads:[~2023-10-19 12:49 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
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 [this message]
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=6149d7a4-f47e-2ac4-91cf-fe144d1a4c63@gutov.dev \
--to=dmitry@gutov.dev \
--cc=63648@debbugs.gnu.org \
--cc=juri@linkov.net \
--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).