all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Kangas <stefan@marxist.se>, emacs-devel@gnu.org
Subject: Re: master c9cb59b 2/2: * etc/TODO: Entry about converting to defvar-keymap.
Date: Sat, 11 Dec 2021 04:02:53 +0100	[thread overview]
Message-ID: <87zgp7x2qq.fsf@gnus.org> (raw)
In-Reply-To: <83ee6ks8rn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Dec 2021 18:51:40 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> Please feel free to revert it if you disagree.
>
> I will, unless Lars disagrees.

Are we talking about reverting the TODO item?  That's fine with me,
because I think it's a bit early to mandate rewriting all the keymaps,
but I do think that should be our long term goal.

Normally I'm against code churn, but that's mainly because it makes it
hard to do code archaeology to determine what the meaning of a
particular piece of code was.  It's often unclear what some piece of
code was meant to achieve, so you have to look at the other changes made
at the same time, and then try to piece things together.

That's not really the case with keymaps, though -- there's little logic
to unravel, so if they change syntactically, it's no big deal.

The advantages of the conversion has to outweigh that "no big deal",
though, but I think in this case they do:

1) In the future, we can envision programmers only having to deal with
one single way to represent key bindings in Emacs Lisp code.  It would
be nice if that were the case, but to get there, we have to covert the
keymaps.

2) The temptation to rewrite a map when doing adding a key or two is
great, but it makes that single commit harder to read.  So converting
maps as a separate commit makes things easier to read, not harder.

3) Today the vast majority of the keys are set as such:

  (define-key calc-mode-map "dp" 'calc-show-plain)

While doing conversion to defvar-keymap, we'd also convert to #', which
gives us byte compilation support for mis-spelled commands.  I found a
couple of bindings that pointed to commands that doesn't exist when
doing the few conversions that I've done.  It's mainly a help when
adding new bindings, of course, but people will cargo cult the previous
line when adding new bindings, and won't get help from the byte compiler.

4) The shorter syntax is less error-prone in general, since you don't
repeat the keymap name in every line.  This means that people that hack
on this in the future will be able to move slightly faster if the maps
have been converted.

5) If we never get to where C-i/TAB can be round-tripped reliably by
other means (Stefan M had some ideas, but I think we stalled?), I have a
patch waiting to fix this by other means -- but not for `define-key', of
course.  So `defvar-keymap'd keymaps will be displayed the same as the
way they were defined in `C-h b', which is nice.

So I'm all for Stefan K continuing to convert keymaps while
procrastinating.

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



  reply	other threads:[~2021-12-11  3:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 15:00 master c9cb59b 2/2: * etc/TODO: Entry about converting to defvar-keymap Eli Zaretskii
2021-12-10 15:37 ` Stefan Kangas
2021-12-10 16:51   ` Eli Zaretskii
2021-12-11  3:02     ` Lars Ingebrigtsen [this message]
2021-12-11  6:20       ` Stefan Kangas
2021-12-10 15:59 ` dick
2021-12-10 16:44   ` Alan Mackenzie
2021-12-11  0:56   ` Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgp7x2qq.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.