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

[Dmitry Gutov <dgutov@yandex.ru>]

On 22.07.2020 02:38, Juri Linkov wrote:

>>> 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.

That's a valid benefit.

There is also a package called 'which-key', but I think it's 
incompatible with the implementation strategy here.

> 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').

If we're using the prompt, it shows all allowed bindings already.

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

At the moment, there's none.

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

Either way, I think the concern that someone could type 'C-x p 4 g' and 
see that the search results are *still* displayed in another window 
(gasp), is not too significant.

Like, there's no other behavior that should result from key sequence, 
and if someone wanted to make doubly sure the resulting buffer will be 
displayed in the other window, why not let them.