[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 <monnier@iro.umontreal.ca> 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:
http://user.it.uu.se/~embe8573