[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Kangas
Subject: Re: master 859190f 2/3: Convert some keymaps to defvar-keymap
Date: Thu, 14 Oct 2021 12:07:04 -0700

Gregory Heytings <gregory@heytings.org> writes:

> Yes, I've seen his reply.  And I do not see what could be cleaner than the
> kbd syntax, which has AFAIK been adopted everywhere, including in the
> tutorial, manuals, error messages, help buffers, and so forth.

For me, it's a no-brainer that we would want to bind keys in the same
way as we display them.

However, that style as implemented by 'kbd' is not without its problems.
It is too allowing in some cases where it would be better to be more

    (kbd "f 1")       => "f1"       ; space is not mandatory
    (kbd "f1")        => "f1"       ; user intended [f1], got "f 1"
    (kbd "<return>")  => [return]
    (kbd "return")    => "return"   ; as above
    (kbd "f ;; foo")  => "f"
    (kbd "f REM foo") => "f"
    (kbd "8*a")       => "aaaaaaaa"
    (kbd "\C-a")      => "^A"       ; fine, but could be disallowed

Stefan Monnier says that we should also be able to say things like
[(control x)], and I have no objections to that.

So the question is not about the format of keybindings, as AFAICT there
seems to exist more or less a consensus around it.  The question is what
API would be useful.

> Frankly, I don't see how this minor, and as I've said almost
> theoretical problem, should force us to create yet another syntax and
> yet another set of key binding functions.

Ambiguity is not a good property to have in our most fundamental
interfaces, IMO.  I think we should not try to retro-fit any DWIM stuff
on the old one, as that will lead to various problems.  It would be
better to provide a new one and promote that as a replacement.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]