[Top][All Lists]

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

Re: confusion with defining keys

From: Emanuel Berg
Subject: Re: confusion with defining keys
Date: Thu, 12 Jun 2014 03:39:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> The reason I do "..." is simply it is easier to
>> type.  So if there is some gain switching I'll do
>> that, of course.
> Using [...] or (kbd "...") gains you the fact that
> these work for *any* key, whereas "..." only works in
> some cases.

It would seem there are some exceptions to that rule!

Check out the below experimentation:

(global-set-key (kbd "RET") 'newline-and-indent) ; works
(global-set-key "\r"        'newline-and-indent) ; works
(global-set-key [RET]       'newline-and-indent) ; (error "To bind the key RET, 
use \"\\r\", not [RET]")

(global-set-key (kbd "M-SPC") 'eat-space) ; works
(global-set-key "\M- "        'eat-space) ; works
(global-set-key [M-SPC]       'eat-space) ; (error "To bind the key M-SPC, use 
\"\\M- \", not [M-SPC]")

Also, with the [...], it seems you shouldn't include
the <...> for custom keys - which is good, because you
don't define them that way, so it is only confusing
having to use that later:

(define-key input-decode-map [?\u010F] [C-semi-colon])
(global-set-key         [C-semi-colon] 'string-to-cmd)
(global-unset-key (kbd "<C-semi-colon>")) ; everything works

A (minor) drawback with [...] is less readability as
the keys don't get the font-lock-string-face -
customizable, of course (but watch out I guess so not
lots of [stuff] get affected).

underground experts united:

reply via email to

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