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

[Spencer Baugh <sbaugh@janestreet.com>]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 19/10/2023 22:30, Spencer Baugh wrote:
>>>>> 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?
>>>> Yes.  Although project-vc-dir and project-dired don't provide a nice
>>>> solution for how to implement the C-x p p single key bindings.  With the
>>>> project-status buffer, if it had the single-key bindings, then we would
>>>> just say "C-x p p resolves keybindings as they would be resolved in
>>>> project-status".
>>>
>>> Hmm... if the goal is to just have 'C-x p p' resolve the short key
>>> bindings, then (setq project-switch-use-entire-map t) gets you all the
>>> way there, doesn't it?
>> To be clear, this was just a comment about how project-status would
>> help
>> us on the implementation side of single-key bindings.  I still
>
> <paragraph unfinished>

I don't remember how I was going to finish it :) Anyway, the point is
moot now, since I'm persuaded that "C-x p p resolves keybindings as they
would be resolved in project-status" doesn't work because of the buffer
change.

>>> BTW, when project-switch-use-entire-map is non-nil, we should probably
>>> display something informative to the user (e.g. some abbreviated list
>>> of all the bindings in project-prefix-map?), so that the users don't
>>> mistake the the meaning of the option, and see at least some of the
>>> keys they can press at that point, instead of the incorrect command
>>> menu.
>> True.
>> Automatically generating this would be kind of like which-key.
>
> I pushed a version of this to master, but one that looks more like
> read-multiple-choice. Reimplementing which-key would be too much, and
> unfortunately I don't see a way to integrate it when available either.

which-key is in GNU ELPA.  So possibly it could be brought into core, if
we're finding that we need it.  Does that seem plausible?  I could bring
it up on emacs-devel, since I think which-key would be an excellent
addition to core for other reasons too.

>>> The latter probably means that we cannot make just any global key
>>> sequence work in the *Project List* buffer (or e.g. have 'M-x gnus'
>>> start in a different directory depending on which line point current
>>> is on). But we might have a binding for a prefix command which would
>>> make sure the next one is run within the project room as its
>>> default-directory. Binding 'project-any-command' (or a variation of
>>> it) to 'o' seems natural in there too. Do you disagree?
>> Hm, I think changing default-directory in project-list based on
>> point is
>> very discoverable.  Let me explain why: When you hit "g" in the
>> project-list buffer, I expect that it would operate on the project at
>> point.  That seems obvious and unobjectionable.  So users will be used
>> to being able to operate on different projects based on the value of
>> point.  And it is (in my experience) a straightforward extension from
>> that to running arbitrary commands on different projects based on the
>> value of point.
>
> 'g' is probably fine. 'f' and the rest of such keys too. Though 'n'
> and, more importantly, 'p' will likely have different expectations.

Yes, I was thinking we'd have 'n' and 'p' do next/previous-line.  'n' is
unused and 'p' is probably not necessary: you can just do C-s instead,
or possibly (if we set it up) use imenu, M-g i.

Possibly we should avoid using C-x p n, to reserve 'n' for this.  (Or
maybe C-x p n could be something that is also not necessary in the
project-list buffer... maybe C-x p n could run project-list?  Maybe it
could be called project-navigate?)

> What if the user presses 'C-x o' while this buffer is current (and
> point is on one of the projects)? Or 'C-x C-s'? Would we dispatch
> every key sequence through our custom prefix command while this buffer
> is current?
>
> I can't think of an particularly damaging example right now, but the
> concept feels moderately dangerous.

Oh, certainly not!  That does sound quite dangerous and complicated and
I have no idea how it would work.

> Buuut... simply changing default-directory buffer-locally in
> post-command hook based on what is under point might be fine.

Yes, that's what I had in mind.  This is much simpler than
other-project-prefix.