bug#43709: minibuffer keybinding cheatsheet and launcher [CODE SUBMISSION]

[Stefan Monnier]

>> [ To see why I say it's not quite ready, here's my experience with it:
>>   I just tried it in a fresh new Emacs session, and after `M-x
>>   key-assist` (which itself is a problem because most users won't
>>   know/bother to run this command way, so we'd need some more "obvious"
>>   way to run it)
> Always a problem with a new feature. When you say 'obvious', you seem to
> mean more than the normal publicizing of a new feature?

I'm thinking that this would be useful for someone that not very
familiar with Emacs, which also explains my further comments about the
behavior.  As it is, it seems instead geared toward users that are
already familiar with Emacs and want to get to know some new mode or
something like that.

For a novice, we'd ideally want the user to be able to find and use this
functionality "naturally" without even knowing beforehand how to look
for it and how Emacs generally works ;-)

>>   I get a prompt for something
> You mean the prompt "Optional: Enter command regexp or keymap name:"?

Yes.

>>   and without reading more the description I wouldn't know what the
>>   prompt wants
> True of very many emacs commands. Not a justification though. It could
> be a multi-line verbose explanatory prompt.

I think skipping the prompt is an easier way to avoid the confusion.
Only prompt if the user asks for it (e.g. with a `C-u` prefix, an
alternative entry-point, ...).

> Reasonable. Could be argued both ways. I have no preference, and just
> thought it friendlier this way to explicitly present to the user all the
> options, especially since this is supposed to be a 'help' function.

Or maybe we'd want to offer this prompt *afterwards*, as a special
command to change&recompute the completion table based on
a new criterion.

>>    and then it said "no choices found".
> That's curious. I haven't seen that in my testing. What was your
> response to the first prompt?

RET

> What was the value of 'major-mode' of the 'current-buffer' when you
> ran the command?

I was in *scratch*, so should have been `lisp-interaction-mode`.
Maybe the "no choices found" message should mention the search string
that was used (that's also a good way to teach the user what the first
prompt means).

>>   So I tried again in a dired buffer, where it instead showed me a
>>   minibuffer prompt "Select: " with no indication of what it is I
>>   should be selecting,
>
> I had difficulty deciding what text to use for this prompt because many
> users can be expected to be using some non-default minibuffer completion
> supplemental package (eg. ido, icicles, ivy), and those all have
> slightly different behavior; many present a result-list without needing
> to TAB.

Good point.  For the plain old default, it would make a lot of sense to
eagerly popup the *Completions*, but I'm not sure how we could do it
without getting in the way for ivy and friends.

> Again, true of very many emacs commands. Not a justification though. I'm
> not a regular on this list, but even slashdot.org is reporting that the
> list has been discussing making emacs friendlier to new users, and I'm
> on board with that, so I'll take any suggestions for improvement here,
> but it might be better done as a patch to 'completing-read'.

Ah, now that makes more sense.  I thought you'd sent your package in the
context of that discussion of improving the experience for novice users.

>> I do think it would be nice to have something like it, since it's an
>> alternative to the menus which has the advantage of being
>> auto-constructed, doesn't need the mouse, and focuses on the keybindings.
> Yep. Also, for me it was important that it present command descriptions,

Agreed.

> even if in the end it came at the expense of omitting command names to
> make the strings shorter.

That's a good tradeoff.

>> It would also be nice to make it usable from minibuffers as well ;-)
> Hmm, I wonder.. Maybe it already does programmatically on a per-case
> basis. Interactively, do you mean integrating into the minibuffer
> codebase? I've long wanted something like this for the minibuffer
> options to isearch-

I'm not sure exactly how it should do it.  But yes, `isearch` is an
obvious use case as well (I say "as well", because isearch doesn't
actually use the minibuffer).

>> >      (while (not (setq choice
>> >                    (cl-position
>> >                      (substring-no-properties ; Is -no-properties 
>> > necessary?
>> >                        (completing-read prompt choices nil t))
>> >                      choices :test 'equal))))
>>
>> Why do you have this loop?  Doesn't the `require-match` arg of
>> `completing-read` make it unnecessary?
>
> I remember thinking so, too, and then needing to add the loop because
> completing-read was accepting a RET. My recollection is that it was
> sending an empty string to cl-position.

Ah, OK, that makes sense.

> But besides all that, it's great, right?

Yes, I like it,


        Stefan