Subject: bug#41890: bug#42210: bug#41890: 28.0.50; [PATCH]: Add bindings for project.el

From: Juri Linkov <[email-masked]>
Date: Wed, 22 Jul 2020 02:38:52 +0300

>>> How about having a project-other-window-commands defcustom for C-x 4 p,
>>> and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
>>> C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
>>> put a static message in the minibuffer like other-frame-prefix and
>>> other-tab-prefix do at present.
>>
>> Just to clarify: are you proposing this because you really like how the
>> prompt works, yet can't find a good way to incorporate it for the two
>> other prefixes?
>
> I wouldn't say that I really like the prompt, but it could be useful to
> someone to see the bindings available to them, when we're sure it's
> going to fit.

While the prompt is active, the key '?' and 'C-h' could (and I think should)
display a list of *ALL* available key bindings from the project keymap
in the *Help* buffer (like e.g. 'query-replace' does after typing 'C-h').

> I do think we should avoid binding commands under C-x 4 where the
> versions under C-x p would already display in another window -- I think
> it is potentially quite confusing to have bindings with identical
> behaviour under both C-x 4 p and C-x p.

Shouldn't some key sequence force displaying the project buffer in the
same window (when a version under C-x p displays it in another window)?

> But that means we need the defcustom, because a user could use
> display-buffer-alist to change which commands under C-x p will use
> another window.

I now understand that your top message above implies that a user
could customize display-buffer-alist to display a buffer in another window,
but usually users don't customize display-buffer-alist to display a buffer
in another frame/tab?