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

[Dmitry Gutov <dmitry@gutov.dev>]

On 21/10/2023 19:09, Spencer Baugh wrote:

>>>> 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.

Even if it were here, I'm not sure what the integration would look like, 
code-wise.

>>>> 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?)

The latter -- sure, probably.