[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: question about Meta + Shift modifiers: M-S-r and M-R
From: |
Drew Adams |
Subject: |
RE: question about Meta + Shift modifiers: M-S-r and M-R |
Date: |
Sat, 26 Jan 2013 08:24:40 -0800 |
> This has nothing to do with Meta.
It has _something_ to do with Meta, in that the same is not true for C-S-r or
C-M-S-r etc. Yes, I understand that Meta chars are a bit special - that's the
point here.
We handle "\M-\S-r" and [(meta shift r)] in `define-key' as `M-R', not as
`M-S-r'. But we do not do the same for (kbd "M-S-r").
Yes, I understand why: because `kbd' accepts an _external_ key representation,
and the external representation of the key specified by "\M-\S-r" or [(meta
shift r)] is `M-R', not `M-S-r'.
AFAICT, there is _no_ possible key with external key representation `M-S-r'.
That is, a user cannot effect such a key sequence. And yet `kbd' accepts that
arg and `define-key' etc. happily creates a binding for it.
> The key S-r (lowercase r with shift modifier) is different from
> R (uppercase R),
One of my questions was this: To what actual keys does the former correspond?
How can a "lowercase r with shift modifier" key ever be manifested by a user?
If it could never be (via keyboard or some other way), then why do we accept it
(and silently)?
> but the keyboard input always translates Shift + lowercase
> letter to the corresponding upper case letter, so it is
> impossible to input S-r.
See above. If it is impossible to manifest a `S-r' key sequence, then why do we
accept it for binding? Why do we actually create a binding to a key that no
user could ever realize?
Note too that for programmatic creation of bindings using `kbd', it can be handy
to handle the shift modifier the same as the others in a program, and to handle
the meta and control modifiers equally. And it would be convenient if `S-r'
were, when used without a control modifier, automatically translated to `R'
(e.g., before the rest of the `kbd' processing).
That's how I stumbled across this: with code that treated the modifiers the same
way. It defined `M-S-r' the same way it defined `C-S-r'. So it ended up
defining a key that no one can type.
And it took me a while to discover the problem, as I was mistakenly thinking of
`M-S-r' and `C-S-r' in the same way. When trying to test/debug, I pressed Meta,
Shift, and `r' and not get the effect I was mistakenly expecting for `M-S-r'.
Another way to think of that proposal might be to consider `M-S-r' as another,
equivalent external representation for the key currently represented only as
`M-R'.
The bottom line is that there is a degree of inconsistency that can lead to
confusion. At least it did in my case, and I was already aware of how Meta
characters work and the fact that there is no `C-R' etc.
See above for possible proposals: either (a) have `kbd' or `define-key' reject
such impossible key sequences or (b) allow `M-S-r' as an additional external
representation (for `kbd') equivalent to `M-R', i.e., automatically translate it
in `kbd'. Maybe there are other, better proposals.
A workaround for the problem, if you decide not to fix it, is to try to dispel
confusion by covering it explicitly in the Elisp manual.