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