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

[Spencer Baugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 19/10/2023 15:22, sbaugh@catern.com wrote:
>> Hm, I personally think having to hit the extra "o" is undesirable.
>> I'm
>> not sure whether "C-x p p o" would be an improvement over the current
>> state of the world: you can already hit "C-x p p D" to run
>> project-dired, so you end up in dired at the root of the project, and
>> then run whatever command you like with default-directory=project-root.
>
> 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.

It does mean that project-unaware commands can't both operate in a
different project and on the current buffer.  Is there ever a place we
actually want that though?

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58784 probably doesn't
> apply (most of the time; unless the projects are nested or whatever).

Indeed.