[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master c9cb59b 2/2: * etc/TODO: Entry about converting to defvar-key
Re: master c9cb59b 2/2: * etc/TODO: Entry about converting to defvar-keymap.
Sat, 11 Dec 2021 04:02:53 +0100
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Eli Zaretskii <email@example.com> 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
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
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no