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

[sbaugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> Hi Juri,
>
> On 22/09/2023 18:52, Juri Linkov wrote:
>>>> Probably. Would you like to propose one? So that I have something to
>>>> compare to, and have something specific to put to the vote as well.
>>>
>>> Ok, something like this:
>> Here is a more tested patch.  It supports these cases:
>> (setq project-switch-use-entire-map t)
>> C-x p p C-b - should not include current buffer in the list of
>> another project (bug#58784)
>> C-x p p f M-n - should fetch the right default file name (bug#58784, 
>> bug#63829)
>> C-u C-x p p f emoji TAB - should include ignored emoji-labels.el (bug#63648)
>> C-x p p C-x d - should visit another project's root (bug#63648)
>> The same with frames:
>> C-x 5 p p C-b
>> C-x 5 p p f M-n
>> C-u C-x 5 p p f emoji TAB - should not show completions in another frame 
>> (bug#65558)
>> C-x 5 p p C-x d
>
> Thank you. Especially for the list.
>
> But I think we still haven't reached a decision whether the "loop
> until correct key is pressed" behavior is useful.
>
> I tried to think how to fit the above requirements into the existing
> model, and it seems to require a new command, and an additional key
> being pressed sometimes, for explicitness.
>
> The attached patch also includes your fix for bug#65558, which seems
> orthogonal to our dilemma, and could probably be installed
> separately. It could be dry-ed up a little, though.
>
> Anyway, with the attached counter-proposal, the list looks like this:
>
> C-x p p C-b - works when project-switch-use-entire-map=t
> C-x p p f M-n - always works
> C-u C-x p p f - same
> C-x p p C-x d - the key sequence is 'C-x p p o C-x d'
>
> With frames:
>
> C-x 5 p p C-b - works when project-switch-use-entire-map=t
> C-x 5 p p f M-n - always works
> C-u C-x 5 p p f emoji TAB - same (thanks to your fix, included)
> C-x 5 p p C-x d - the key sequence is 'C-x 5 C-x p p o C-x d'
>
> The user could add project-list-buffers (or project-switch-to-buffer)
> to project-switch-commands, though, and then
> project-switch-use-entire-map won't be needed. Either way's fine.
>
> To sum up, that does require pressing an extra key to use commands
> outside of project-prefix-map, but OTOH that key is shown right in the
> commands menu. And one doesn't have to (setq
> project-switch-use-entire-map t) to use it, though that doesn't hurt
> either.
>
> And the meaning of project-switch-use-entire-map remains as it
> currently is: expand the set of keys to the whole project-prefix-map,
> but not to all local and global ones.
>
> WDYT?

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.

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.

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.

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.