GNU bug report logs - #74999
[PATCH v2] Recommend `keymap-set' instead of `define-key' in emacs lisp intro

Previous Next

Package: emacs;

Reported by: Hong Xu <hong <at> topbug.net>

Date: Fri, 20 Dec 2024 21:45:02 UTC

Severity: wishlist

Tags: patch

Merged with 74983

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Hong Xu <hong <at> topbug.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74999 <at> debbugs.gnu.org
Subject: bug#74999: [PATCH v3] Recommend `keymap-set' instead of `define-key' in emacs lisp intro
Date: Thu, 26 Dec 2024 13:58:33 -0800
Thanks for reviewing. Please see my followup patch.

On 2024-12-26 Thu 00:20 GMT-08, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Hong Xu <hong <at> topbug.net>
>> Date: Sat, 21 Dec 2024 00:03:54 -0800
>> 
>> * Since `define-key' is considered legacy and we encourage `keymap-set'
>>   now.
>> ---
>>  doc/lispintro/emacs-lisp-intro.texi | 25 ++++++++++++++++++-------
>>  1 file changed, 18 insertions(+), 7 deletions(-)
>
> Thanks.  I tried to install this, but the git-commit hook rejected the
> commit because Subject line is too long:
>
>   Line longer than 78 characters in commit message
>   Commit aborted; please see the file CONTRIBUTE
>
> Please format the patch using "git format-patch", and please commit
> the patch locally before you do so (assuming you have the hooks in
> your local clone), to make sure these problems are corrected before
> you send the patch here.

I could apply these patches without line length complaints, and the
hooks were in effect. An inspection into the patch file also shows no
line is longer than 78 characters. Git is supposed to abandon the
"[Patch vN]" prefix when applying the patch.

> More generally, global-set-key, discussed earlier in this section, is
> also obsolete, and we nowadays prefer keymap-global-set instead.  So,
> if we want to modernize this part of the Emacs Lisp Intro manual, I
> think we should replace all the key-binding examples and the
> surrounding text in the manual to use the new keymap-* functions.  It
> makes little sense to replace only define-key and leave the rest as
> they were.
>
> Would you like to submit a patch that takes care of these issues in a
> more thorough manner?

Addressed.
>
>> +While you are encouraged to use @code{keymap-set}, you likely would
>> +encounter @code{define-key} in various places.  Historically, keymaps
>> +are bound using a lower-level function, @code{define-key}, which
>> +is now considered legacy.
>
> These two sentences should be in reverse order: first tell that
> historically we used define-key, then say that the reader is
> encouraged to use keymap-set.
>

Addressed.




This bug report was last modified 136 days ago.

Previous Next


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