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

[Jeremy Bryant]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 68929@debbugs.gnu.org, monnier@iro.umontreal.ca, justin@burkett.cc
>> Date: Wed, 07 Feb 2024 21:48:00 +0000
>> From:  Jeremy Bryant via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 
>> Philip Kaludercic <philipk@posteo.net> writes:
>> 
>> > My genera feeling is that the code is reinventing the wheel at a number
>> > of places, which might make it more complicated to maintain in the long
>> > term.  Looking for ways to slim down the codebase, perhaps by
>> > deprecating some options, dropping support for third-party packages and
>> > reusing existing functionality seems like something one should look into.
>> 
>> Should these improvements be made before moving which-key to core?
>
> Preferably, yes.

Eli/Philip,

Here is a progress update.

For convenience please find attached a v2 version of which-key with the
improvements (in conjunction with Justin). This includes

* All improvements requested by Eli; docstrings, :verion tags,
etc.. - with the exception of the redesign point for character widths

* The vast majority of improvements requested by Philip; defcustoms
changes, docstrings, sharp-quoted elements, pure function, third party
libs, declare, memq, string-join, null-bindings etc) Missing are some
elements I'm less familiar with, such as design choices related to
deffaces.

These are currently in the form of individual patches in the upstream
git repo (thus attached only for convenience).  Using the 'preserving
history' approach described by Stefan M, this could be moved to core,
thus preserving the commits thus allowing checking of contributor FSF
attribution.


If there are certain elements you feel deserve further work, all
feedback welcome.

WDYT?

which-key-v2.el
Description: application/emacs-lisp