GNU bug report logs - #43709
minibuffer keybinding cheatsheet and launcher [CODE SUBMISSION]

Previous Next

Package: emacs;

Reported by: Boruch Baum <boruch_baum <at> gmx.com>

Date: Tue, 29 Sep 2020 17:01:01 UTC

Severity: normal

Tags: patch, wontfix

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43709 in the body.
You can then email your comments to 43709 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Tue, 29 Sep 2020 17:01:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Boruch Baum <boruch_baum <at> gmx.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 29 Sep 2020 17:01:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Subject: minibuffer keybinding cheatsheet and launcher [CODE SUBMISSION]
Date: Tue, 29 Sep 2020 12:59:57 -0400
[Message part 1 (text/plain, inline)]
If you've ever used packages such as `ivy' or `magit', you've probably
benefited from each's custom combination keybinding cheatsheet and
launcher: `hydra' in the case of `ivy', and `transient' for `magit'. The
attached package `key-assist' attempts to offer a generic and very
simple alternative requiring only the `completing-read' function
commonly used in core vanilla emacs. `key-assist' is trivial to
implement "on-the-fly" interactively for any buffer, and
programmatically much simpler to customize that either `hydra' or
`transient'. And did I mention that it only requires `completing-read'?

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
[key-assist.el (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Tue, 29 Sep 2020 17:42:02 GMT) Full text and rfc822 format available.

Message #8 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>, 43709 <at> debbugs.gnu.org
Subject: RE: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Tue, 29 Sep 2020 10:41:36 -0700 (PDT)
> If you've ever used packages such as `ivy' or `magit', you've probably
> benefited from each's custom combination keybinding cheatsheet and
> launcher: `hydra' in the case of `ivy', and `transient' for `magit'. The
> attached package `key-assist' attempts to offer a generic and very
> simple alternative requiring only the `completing-read' function
> commonly used in core vanilla emacs. `key-assist' is trivial to
> implement "on-the-fly" interactively for any buffer, and
> programmatically much simpler to customize that either `hydra' or
> `transient'. And did I mention that it only requires `completing-read'?


Cf. `keysee.el'

https://www.emacswiki.org/emacs/KeySee

https://www.emacswiki.org/emacs/download/keysee.el




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Tue, 29 Sep 2020 18:23:01 GMT) Full text and rfc822 format available.

Message #11 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Tue, 29 Sep 2020 14:22:19 -0400
[Message part 1 (text/plain, inline)]
On 2020-09-29 10:41, Drew Adams wrote:
> Cf. `keysee.el'
>
> https://www.emacswiki.org/emacs/KeySee
>
> https://www.emacswiki.org/emacs/download/keysee.el

Oh. Had I known... Would I? / Wouldn't have I? From reading the
emacswiki description, it seems that there are some differences in
presentation. My motivation was specifically to write just a few lines
for an element of another code submission I have pending, and then the
idea got out of control. It didn't occur to me to check emacs-wiki.

BACKGROUND: I have a collection of dired extensions that'll be ready for
submission as soon as I complete the documentation. It includes a set of
'trash' management functions, eg. smart empty trash, restore trashed
file(s), report trash status. But who can be expected to remember all
the arcane keybindings of all the arcane modes? So I wrote it hard-wired
for about four commands of diredc-trash, and then ...

ATTACHED: I'm attaching that original function because someone may ask
why include in `key-assist.el' a programmatic option to supply a list of
elements (command . function). In the attached example, you can see that
I'm presenting a description of the command `diredc-trash-toggle' based
upon what it would do at any particular time.

FOLLOW-UP: Another follow-up might be to supply some specific code for
some notorious major modes. I'm thinking in particular of `calc-mode',
which is such a beauty-in-the-rough, but suffers from a particularly bad
case of keybinding hell (it also suffers from a consistent absence of
docstrings).

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
[diredc-trash-assistant.el (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Tue, 29 Sep 2020 18:27:01 GMT) Full text and rfc822 format available.

Message #14 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Tue, 29 Sep 2020 14:26:39 -0400
Also, note how in the `diredc-trash-assistant' prototype, how I
exploited the PROMPT arg to sneak in extra status information.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Tue, 29 Sep 2020 19:08:02 GMT) Full text and rfc822 format available.

Message #17 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43709 <at> debbugs.gnu.org
Subject: RE: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Tue, 29 Sep 2020 12:05:23 -0700 (PDT)
> Oh. Had I known... Would I? / Wouldn't have I? 

Yes, you should.  And thanks for doing so.

Dunno whether filing a bug is the best way to
provide it, but that will work, no doubt.

Another possibility is to use emacs-devel <at> gnu.org.
Many more people read that mailing list,
including most who also pay attention to the
bug list.

> BACKGROUND: ...
> ATTACHED: ...
> FOLLOW-UP: ...

That all sounds good.  Keep it up.

FYI: Another related library is `which-key.el',
which you may already be aware of.

https://github.com/justbur/emacs-which-key




Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 30 Sep 2020 01:57:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 01 Oct 2020 13:52:01 GMT) Full text and rfc822 format available.

Message #22 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Thu, 01 Oct 2020 09:51:36 -0400
> If you've ever used packages such as `ivy' or `magit', you've probably
> benefited from each's custom combination keybinding cheatsheet and
> launcher: `hydra' in the case of `ivy', and `transient' for `magit'. The
> attached package `key-assist' attempts to offer a generic and very
> simple alternative requiring only the `completing-read' function
> commonly used in core vanilla emacs. `key-assist' is trivial to
> implement "on-the-fly" interactively for any buffer, and
> programmatically much simpler to customize that either `hydra' or
> `transient'. And did I mention that it only requires `completing-read'?

I'm not completely sure what is the intended use scenario.

I mean, I understand the package is not 100% ready, so I'm interested to
know how you imagine it working *ideally* once the various kinks have
been sorted out.

[ 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) I get a prompt for something and without reading more
  the description I wouldn't know what the prompt wants (I think this
  prompt should only appear if requested explicitly) and then it said
  "no choices found".  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, after that I hit TAB (because I read
  that it uses `completing-read`, but for the un-initiated it might not
  be obvious) at which point it did show me a list of bindings and short
  descriptions and when I selected the first entry (i.e. `!`) it
  signal'd an error about wrong number of arguments.  ]

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.
It would also be nice to make it usable from minibuffers as well ;-)

See some comments below based on a quick look at the code.


        Stefan


> ;;   If you've ever used packages such as `ivy' or `magit', you've

For those who haven't, it would be good to describe what your package does.

> ;;; Dependencies:
>
> ;; `cl-seq' - For `cl-position', but `cl-lib' is long part of all
> ;;            modern emcasen.

There's no such thing as a `cl-seq` package.
There's a `cl-seq.el` file, which is part of the `cl-lib` package.

> (require 'cl-seq) ;; cl-member, cl-position

Please require `cl-lib` rather than `cl-seq` since which function is
implemented in which file of `cl-lib` is an internal detail (e.g. in
Emacs-24.1 `cl-seq` does not provide `cl-position` but `cl-lib` still does).

> (defun key-assist--get-keybinding (cmd &optional key-map)
>   "Return a string with CMD's shortest keybinding."
>   (let (shortest)
>     (dolist (key (mapcar 'key-description
>                          (where-is-internal
>                            cmd key-map nil t)))
>       (when (or (not shortest)
>                 (> (length shortest) (length key)))
>         (setq shortest key)))
>     shortest))

`where-is-internal` is supposed to return the shortest binding already
when asked to return the "firstonly".  Your notion of length is slightly
different, admittedly, but I wonder what were the concrete cases that
motivated doing your own sorting (might be worth adding that as
a comment in the code).

>     (let ((not-found t))
>       (mapc (lambda (x)
>               (when (string-match x (format "%s" cmd))
>                 (setq not-found nil)))
>             key-assist-exclude-regexps)
>       not-found)))

You should move the `(format "%s" cmd)` out of the loop (and use
`dolist` instead of `mapc`).

>      ((keymapp spec)
>        (let (cmd)
>          (dolist (elem spec)

Please use `map-keymap` rather than `dolist` so as to handle all the
different keymap formats.

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

>      (funcall (car (nth choice commands))))))

This should probably be `command-execute` rather than `funcall` to fix
the wrong-number-of-arguments error I bumped into.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 01 Oct 2020 15:33:01 GMT) Full text and rfc822 format available.

Message #25 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Thu, 1 Oct 2020 11:31:47 -0400
On 2020-10-01 09:51, Stefan Monnier wrote:
> I'm not completely sure what is the intended use scenario.

1) Interactively...

1.1) A user finds himself in an unfamiliar mode buffer, and isn't sure
     what that mode's options are and how to use them. You mention
     further that you tried it in a dired-mode, so you saw its default
     operation in such a case. For dired-mode, the result-list is very
     long; for other modes, such as occur-mode or a packages buffer,
     you'll get a shorter list. The more obscure the mode, the more
     useful this use-case.

1.2) A user has a vague idea of a command name of interest, so enters a
     regex or substring of it to see a list of keybindings and
     descriptions of matches (as relevant for the current buffer).

2) Programmatically...

2.1) A developer wants to offer a cheat sheet / launcher for a package
     (similar in function to transient/hydra) but with less programming.
     This package offers wide latitude of how to compose a command list,
     what to display, how to sort, how to prompt. The args can be
     trivially simple to quite complex.

     (defun my-mode-low-budget-transient ()
       (interactive)
       (when (eq major-mode my-mode)
         (key-assist ...)))
     (define-key my-mode-map "?" 'my-mode-low-budget-transient)

BTW, On the emacs-bug thread/URL, I shared with Drew Adams the
original inspiration for the package, which includes the motivation for
what seems like an obscure arg option (cmd . function)

> [ 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 get a prompt for something

You mean the prompt "Optional: Enter command regexp or keymap name:"?

>   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 this prompt should only appear if requested explicitly)

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.
Programmatically, this prompt shouldn't ever appear.

>    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? What was the value of 'major-mode' of the
'current-buffer' when you ran the command?

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

>   after that I hit TAB (because I read that it uses `completing-read`,
>   but for the un-initiated it might not be obvious)

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

>   at which point it did show me a list of bindings and short
>   descriptions and when I selected the first entry (i.e. `!`) it
>   signal'd an error about wrong number of arguments. ]

Got it. Thanks much for your concrete suggestion further down on how to
correct this bug. Many of the other options *DO* work though; this is a
bug in the improper way the function calls some interactive functions.

> 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,
even if in the end it came at the expense of omitting command names to
make the strings shorter.

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

> See some comments below based on a quick look at the code.

I appreciate the comments a lot. Thanks for the constructive review.

> `where-is-internal` is supposed to return the shortest binding already
> when asked to return the "firstonly".

I wasn't getting my desired result with it..

> Your notion of length is slightly different, admittedly, but I wonder
> what were the concrete cases that motivated doing your own sorting

Oops. Forgetting just now. A secondary motivation for the sort was to
offer multiple sort options. In the end, I left it as an option for
programmers to pass their own sort function. For example, someone may
want to treat prefixes / upper-case differently.

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

> ....

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

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 01 Oct 2020 16:05:01 GMT) Full text and rfc822 format available.

Message #28 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Thu, 01 Oct 2020 12:04:45 -0400
>> [ 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 01 Oct 2020 18:26:02 GMT) Full text and rfc822 format available.

Message #31 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Thu, 1 Oct 2020 14:25:04 -0400
On 2020-10-01 09:51, Stefan Monnier wrote:
> > ;;   If you've ever used packages such as `ivy' or `magit', you've
> For those who haven't, it would be good to describe what your package does.

In progress...

> > (require 'cl-seq) ;; cl-member, cl-position
> Please require `cl-lib`grather than `cl-seq`

Done.

> >     (let ((not-found t))
> >       (mapc (lambda (x)
> >               (when (string-match x (format "%s" cmd))
> >                 (setq not-found nil)))
> >             key-assist-exclude-regexps)
> >       not-found)))
>
> You should move the `(format "%s" cmd)` out of the loop (and use
> `dolist` instead of `mapc`).

Done, but I went with symbol-name instead of format.

> >      ((keymapp spec)
> >        (let (cmd)
> >          (dolist (elem spec)
>
> Please use `map-keymap` rather than `dolist` so as to handle all the
> different keymap formats.

I had tried that originally, but map-keymap brings in data from parent
keymaps, which is undesirable in this case. There is a function
map-keymap-internal which might be a usable alternative, but it returns
a single unusable cruft element (the parent keymap) when it exists, so
the result doesn't seem much better than the current code, no?

> >      (funcall (car (nth choice commands))))))
>
> This should probably be `command-execute` rather than `funcall` to fix
> the wrong-number-of-arguments error I bumped into.

Great catch. It solves the bug you found. Done.

As for posting updates to the code submission, I can do any combination of
the following, or something else, but want guidance before proceeding:

1) post to this list;

2) post to the pre-existing thread on emacs-bugs;

3) create a github repo, and post there (and gain potential wider
audience, more features, but fragment communication over two platforms);

4) create a repo on some imagined savannah / gnu server;

Finally: Tomorrow approaching sunset I go offline for about nine
days[1], so what I can squeeze in before then, great; afterwards I
welcome any continued feedback but please be patient and don't expect
any response for ~10-12 days.

But really finally this time: I've twice already made passing reference
to another package about ready to submit, that adds a lot of new
functionality to dired. I can post it now in its current state, and
inconsiderately disappear offline for 9+ days, or I could just as
inconsiderately not post it and deny you for 9+ days. I'm undecided, so
unless I hear otherwise, I'll wait.

--
[1] https://en.wikipedia.org/wiki/Sukkot

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 01 Oct 2020 20:47:02 GMT) Full text and rfc822 format available.

Message #34 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Thu, 1 Oct 2020 16:46:17 -0400
On 2020-10-01 12:04, Stefan Monnier wrote:
> I'm thinking that this would be useful for someone that not very
> familiar with Emacs,

It could be, yes.

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

True.

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

Oh, emacs. I'm the wrong person to ask because my reflexive response was
to assume everyone should expect something like 'C-u C-h k'.

BTW, a few months (years?) ago I had an email exchange with Eli
Zaretskii in which he mentioned the help feature that he felt was most
useful and important ... and it turned out not to even have a
keybinding o even a mention in 'C-h ?' (and now I've forgotten even what
it was the command was...)

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

My initial inclination was to go for the prefix-arg option, but that
wouldn't be friendly to novice users. And then I thought the same thing
about an alternative entry-point, because it's asking someone to
remember two separate commands. If the goal is to deal with the
confusion of novices, the way to do it is with a single command and
verbose interface. Even for non-novices, the goal here is to reduce the
requirement to memorize, so having multiple ways of invoking the command
is contradictory in that it asks for more memorization. A golden mean
would be to come up with a short and clear prompt that can be ignored
for most cases.

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

Not difficult to program, but when I think about it, I see two
obstacles:

1) The prompt ends up being at least as messy or confusing. What I end
   up with is a three-line prompt, something like (example being a dired
   buffer):

     Presenting list of 'dired-' commands.
     Select an item on the current list, or
     <key> to present a list using a different regexp

2) What <key> could you use to guarantee no conflict with any other
   entry on the list? Remember that we're inside 'completing-read' at
   this point, so we can't be using control characters, can we? Even if
   we can dynamically change the <key> based upon a uniqueness check of
   all characters in the list, that would just add to confusion, because
   each different invocation would generate a different <key>. In
   practice, it would be difficult to generate such a unique key because
   completing-read matches against all characters in list, which in our
   case includes all characters in the description, not just those of
   the keybindings.

> >>    and then it said "no choices found".
> 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).

Agreed. I'll work on it. My preference would then be for a verbose
minibuffer message, maybe as much as three long lines, amounting to a
mini-tutorial, the goal being to reduce confusion for novices or people
unfamiliar with the operation.

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

Is this again something to consider implementing as a patch inside
completing-read, ie. change the message/prompt inside completing-read;
would users of the packages that commandeer the mini-buffer interface
("ivy and friends") see the completing-read prompt at that point? At
that point, they've already commandeered the interface.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Fri, 02 Oct 2020 07:15:01 GMT) Full text and rfc822 format available.

Message #37 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: 43709 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Emacs-Devel List <emacs-devel <at> gnu.org>
Subject: bug#43709: minibuffer keybinding cheatsheet and launcher [V2 CODE
 SUBMISSION]
Date: Fri, 2 Oct 2020 03:14:19 -0400
[Message part 1 (text/plain, inline)]
Here's an update to key-assist.el:

1) Improved commentary documentation and more helpful prompts

2) Fixes a launcher bug

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
[key-assist.el (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Fri, 02 Oct 2020 18:25:01 GMT) Full text and rfc822 format available.

Message #40 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>, 43709 <at> debbugs.gnu.org
Cc: Emacs-Devel List <emacs-devel <at> gnu.org>
Subject: RE: bug#43709: minibuffer keybinding cheatsheet and launcher [V2 CODE
 SUBMISSION]
Date: Fri, 2 Oct 2020 11:24:44 -0700 (PDT)
Please don't send messages to both the bug list and emacs-devel.  Please pick one.  Thx.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 15 Oct 2020 18:55:01 GMT) Full text and rfc822 format available.

Message #43 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: 43709 <at> debbugs.gnu.org
Cc: 43709 <at> debbugs.gnu.org, Emacs-Devel List <emacs-devel <at> gnu.org>
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [V3
 CODE SUBMISSION]
Date: Thu, 15 Oct 2020 14:53:48 -0400
[Message part 1 (text/plain, inline)]
It's been two weeks since I heard any feedback on this proposal. Can I
nudge? What's the decision for future action or inaction on this?
Attached is the same content with some minor documentation changes,
mainly to comply with checkdoc and package-lint.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
[key-assist.el (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 15 Oct 2020 19:00:02 GMT) Full text and rfc822 format available.

Message #46 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>, 43709 <at> debbugs.gnu.org
Cc: 43709 <at> debbugs.gnu.org, Emacs-Devel List <emacs-devel <at> gnu.org>
Subject: RE: bug#43709: minibuffer keybinding cheatsheet and launcher [V3 CODE
 SUBMISSION]
Date: Thu, 15 Oct 2020 11:57:00 -0700 (PDT)
Please don't send the same message to both the bug list and emacs-devel.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Wed, 21 Jul 2021 12:16:01 GMT) Full text and rfc822 format available.

Message #49 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Wed, 21 Jul 2021 14:14:58 +0200
Boruch Baum <boruch_baum <at> gmx.com> writes:

> It's been two weeks since I heard any feedback on this proposal. Can I
> nudge? What's the decision for future action or inaction on this?

I've tried out this package, and it's interesting, but I don't think
it's generally useful enough to include in Emacs.  But packaging it up
for ELPA might make sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 21 Jul 2021 12:16:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 43709 <at> debbugs.gnu.org and Boruch Baum <boruch_baum <at> gmx.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 21 Jul 2021 12:16:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Wed, 21 Jul 2021 13:49:02 GMT) Full text and rfc822 format available.

Message #56 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Wed, 21 Jul 2021 09:48:22 -0400
On 2021-07-21 14:14, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
> > It's been two weeks since I heard any feedback on this proposal. Can I
> > nudge? What's the decision for future action or inaction on this?
>
> I've tried out this package, and it's interesting, but I don't think
> it's generally useful enough to include in Emacs.  But packaging it up
> for ELPA might make sense.
>

Done.
+ https://github.com/melpa/melpa/pull/7198
+ https://melpa.org/#/key-assist

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43709; Package emacs. (Thu, 22 Jul 2021 06:50:02 GMT) Full text and rfc822 format available.

Message #59 received at 43709 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43709 <at> debbugs.gnu.org
Subject: Re: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE
 SUBMISSION]
Date: Thu, 22 Jul 2021 18:49:47 +1200
On 2021-07-22 01:48, Boruch Baum wrote:
> On 2021-07-21 14:14, Lars Ingebrigtsen wrote:
>> I've tried out this package, and it's interesting, but I don't think
>> it's generally useful enough to include in Emacs.  But packaging it up
>> for ELPA might make sense.
> 
> Done.
> + https://github.com/melpa/melpa/pull/7198
> + https://melpa.org/#/key-assist

I suspect the suggestion was GNU ELPA rather than MELPA.

In any case, as you've already proposed it for Emacs, do consider
submitting it to GNU ELPA.

-Phil





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 19 Aug 2021 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 222 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.