Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's confusing because it'd be a different syntax for define-key and
> define-keymap.
>
> If we were redesigning all the Emacs keymap functions from scratch, I'd
> go with the `kbd' syntax for keys, but unfortunately we aren't.

Aha.  Now I understand the argument.  But surely that's pretty minor,
given that we can just document this difference?  People might
appreciate the easier to read syntax many times more than they will
struggle with this minor additional complexity.

It seems somewhat unfortunate to me that we are effectively doubling
down on the mistakes of the past.  I'd rather take one step forward now,
in the hope that we can do something about "define-key" later.

I think it's clear that an important section of the Emacs user-base
values a more succinct and clear style higher than the idioms and
idiosyncrasies of the past.  This has affected Emacs in many positive
ways over the years, see for example how dash.el prompted the
development of seq.el, etc.

With regards to keybindings, I think many agree with you that the kbd
syntax is better.  But people are not sitting still.  On the contrary,
there is a lot of experimentation taking place in third-party packages
specifically to avoid having to use `define-key'.  See e.g.:

    https://github.com/jwiegley/use-package/blob/master/bind-key.el
    https://github.com/noctuid/general.el
    https://github.com/justbur/emacs-which-key#keymap-based-replacement
    https://evil.readthedocs.io/en/latest/keymaps.html#evil-define-key

Over time, and if we don't take action, this risks leading to a
proliferation in various conflicting and incompatible styles, that all
depend on this or that third-party package.  Meanwhile, Emacs yet again
looks archaic and too stuck in our old ways.

I suggest that we would do better, and perhaps partially pre-empt such a
development, by taking a pro-active stance with a new construct like
`define-keymap'.