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: Thu, 31 Aug 2023 19:36:29 +0300 [thread overview]
Message-ID: <86wmxb2qvh.fsf@mail.linkov.net> (raw)
In-Reply-To: <d2b7993b-73a8-6e66-94ae-da8f4fc42ffd@gutov.dev> (Dmitry Gutov's message of "Thu, 31 Aug 2023 14:13:46 +0300")
>>> - Unfortunately, using default-directory instead of the specialized
>>> variable which we added lately (project-current-directory-override)
>>> brings back the bug it was added for: https://debbugs.gnu.org/58784. The
>>> switch to a different design didn't fix the problem of the temporary
>>> binding for d-d in the buffer which is current when the command is
>>> executed. So adding the next-default-directory variable might not be the
>>> best idea after all. But the advice thingy can set a binding for any
>>> variable, including the *-override one.
>> I didn't test yet the cases from bug#58784. So this might require more
>> changes.
>
> We tried to make the default-directory binding work with a couple of
> different changes - it didn't work out.
The problem is that let-binding overrides the buffer-local value:
```
(let ((default-directory "/tmp/"))
(list default-directory
(buffer-local-value 'default-directory (current-buffer))))
=> ("/tmp/" "/tmp/")
```
Here is the shortest test case: 'C-x p p C-b' shows buffers
from two projects when using let-binding for default-directory,
because 'project-buffers' relies on
(buffer-local-value 'default-directory buf)
This could be fixed by adding special-handling of the default-directory
for the current buffer in 'project-buffers'.
>>> - I also managed to get into some transient state where some chars were
>>> doing one thing (their usual bindings), and some - invoked project
>>> commands instead, with no apparent method of quitting that state. Maybe
>>> I'll document it next time I see it.
>> It would be nice to have a reproducible test case.
>> But indeed chars in the project map invoke the project commands,
>> and all other chars fall back to local/global keybindings.
>>
>>> - Using (project--keymap-prompt) for just a message call is cute, but
>>> I personally like the "guardrails": if I accidentally type a wrong char
>>> when choosing the command, I won't have to choose the other project
>>> again. This is debatable, but both modes of operation are probably worth
>>> keeping available (opinions welcome).
>> This is easy to do with something like in 'y-or-n-p-map'.
>
> With setting that (or similar) keymap as a transient keymap?
Something like this.
>>> - Either way, with method with the advice should be useful for other
>>> things, like project--other-place-command.
>> It's not recommended to use advice in the core packages,
>> maybe only for providing backward-compatibility with older versions.
>
> Sure, but it should also be permissible when there is no other way to do
> a thing.
>
> OTOH, if we're talking about new features in core, we could have
> a next-command-variables-alist, where we'd bind any variables that we would
> want.
Such generalization could be added later.
> A general question regarding this approach, for me, is: is a "prefix
> command" a real command?
It's a real command that prepares some transient values for the next command.
Most existing prefix commands have no problems because they modify global
values. But 'default-directory' is the first buffer-local variable
used for the next command, therefore it requires special-handling.
Too bad that 'default-directory' is not a function.
> And would they "swallow" these prepared variable bindings too early?
The scope of the modified variable depends on concrete needs.
For example, set-transient-map restores its old value in pre-command-hook,
but display-buffer-override-next-command does this in post-command-hook.
next prev parent reply other threads:[~2023-08-31 16:36 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 [this message]
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
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=86wmxb2qvh.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).