It makes this capability apparent, and it's still one fewer keystroke
(and 'o' is close to 'p', too).
One fewer keystroke? Oh, since one has to hit shift to type
D... there's equivalently C-x p p v, then, which is the same length in
keystrokes.
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?
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".
BTW, a more tangential idea: a list-projects command and associated
*Project List* buffer would be nice. With:
- a list of all remembered projects, with some details about each one
- you can hit RET to open a project's project-status
- with something (a post-command-hook?) which updates default-directory
so that it matches the project at point, so commands you run operate
on that project (e.g. find-file)
- and the same single key bindings that are in project-prefix-map
(maybe C-x p RET should be the binding to open project-status in general)
This would be a nice complement to project-switch-project: list-projects
and project-switch-project would be like list-buffers and
switch-to-buffer.
(The combination of list-projects and project-status buffers would
basically be a port of what we have internally at Jane Street. While
I'm saying that, I should mention also our equivalent of
project-switch-project: when passed a prefix argument, all our
equivalent-to-project-* commands will prompt for a project. This is not
a great solution though, it doesn't scale well since every command needs
to be aware of this prefix argument. The C-x p p design of a separate
command which overrides the project for the next command is much better,
and once we get a good design I plan to tell our users to start using
C-x p p for our internal commands instead of passing the prefix
argument.)
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,
I was thinking we'd solve both this specific problem and the general
case by just saving the current buffer in a project-old-buffer variable
so that project-aware commands could go back and grab stuff from it.