bug#68929: [PATCH] Copy which-key from GNU ELPA into core

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> 1. I think replacing third-party support with hooks that will allow
> whatever package to insert code where needed is a good idea, although
> some of these packages (like evil) have some pretty idiosyncratic
> needs if I remember correctly.

Indeed, resolving such issues can be non-trivial (especially when they
require synchronization with other packages).

Often we end up doing it in two steps: first introduce the hook (making
sure that it is flexible enough that it can cover our needs and those
of other packages), then later remove the ad-hoc third-party support.

> 3. There were some oddities that we ran into early on around computing
> the width of unicode characters that I did not fully understand, which
> is why there are some clunky options for those. The main issue was
> some characters came out wider than anticipated, breaking the width
> calculations for the table shown by which-key. I would be happy to
> improve those with guidance.

For monospace fonts, `string-width` *should* give you the information
you need.

> 4. I never really liked the timer mechanism either, but I didn't find
> an alternative to detecting when emacs was in the middle of reading a
> key sequence. I like the idea of which-key as simply being a different
> describe-prefix-bindings function, but my sense is that novices
> appreciate the automatic popup. I'm wondering if anyone has any other
> ideas. In principle, one could have a hook that emacs uses to notify
> which-key that emacs is waiting on a key sequence, but maybe that is
> overkill.

I don't have a strong opinion about the use of a timer.
But maybe we could hook into the `echo-keystrokes` mechanism (and thus
reuse its timer, which also defaults to 1s).


        Stefan