question about Meta + Shift modifiers: M-S-r and M-R

question about Meta + Shift modifiers: M-S-r and M-R

[Drew Adams]

Someone will hopefully remind me of something simple that has disappeared from
my memory at the moment.  Or perhaps there is a bug somewhere?  I really don't
know what I might be missing at this point.

Why is it that `M-S-r' is not the same key sequence as `M-R', at least
sometimes?

(global-set-key "\M-\S-r" 'forward-char)
C-h k ; then press Alt + Shift + r
Says that M-R is bound to `forward-char'.

(global-set-key (kbd "M-R" 'forward-char)
has the same effect.

Fair enough.  But is calling this `M-R' just a nice shorthand,
or does Emacs simply not consider this key sequence as being
the same as `r' plus the modifiers Meta and Shift?

(global-set-key "\M-\S-r" nil) ; Cancel that.

(global-set-key (kbd "M-S-r" 'forward-char)

C-h w forward-char says that it is on `M-S-r'.
C-h k ; press the same chord.
Says the same thing it said when bound to nil.

`M-S-r' is acceptable as a key sequence for binding, and it gets bound as
expected, but it apparently does not mean the same thing as pressing that chord.
What possible combination of physical keys might it actually represent?

Which part of the manual am I not finding or misreading, which would explain all
of this?  Searching for `Shift', which the discussion would presumably need to
mention, finds nothing pertinent, AFAICT.  Likewise, searching for `uppercase'
and `lowercase'.

It seems clear (now) that the _only_ external representation that Emacs uses and
recognizes for that chord is `M-R'.  That would explain why (kbd "M-S-r") does
not do the same thing.

But (kbd "M-S-r") is acceptable and clearly binds _some_ key sequence - which
one?  What real key sequence does it represent?  Or what irreal one could it
represent, given an arbitrary fictional keyboard?

Somehow I mistakenly got the impression that `M-S-r' would be just another
external way to refer to the same chord that `M-R' refers to.

Re: question about Meta + Shift modifiers: M-S-r and M-R

[Andreas Schwab]

This has nothing to do with Meta.  The key S-r (lowercase r with shift
modifier) is different from R (uppercase R), but the keyboard input
always translates Shift + lowercase letter to the corresponding upper
case letter, so it is impossible to input S-r.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: question about Meta + Shift modifiers: M-S-r and M-R

[Drew Adams]

> 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.

Re: question about Meta + Shift modifiers: M-S-r and M-R

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> It has _something_ to do with Meta, in that the same is not true for C-S-r or
> C-M-S-r etc.

(equal (kbd "C-S-r") (kbd "C-R")) => nil
(equal (kbd "C-M-S-r") (kbd "C-M-R")) => nil

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: question about Meta + Shift modifiers: M-S-r and M-R

[Drew Adams]

> > It has _something_ to do with Meta, in that the same is not 
> > true for C-S-r or C-M-S-r etc.
> 
> (equal (kbd "C-S-r")   (kbd "C-R"))   => nil
> (equal (kbd "C-M-S-r") (kbd "C-M-R")) => nil

So what?

(equal (kbd "M-S-r")   (kbd "M-R"))   => nil
(equal (kbd "C-M-S-r") (kbd "C-M-R")) => nil

(global-set-key (kbd "C-S-r") 'forward-char)
C-h w forward-char correctly tells us it is on `C-S-r'.

(global-set-key (kbd "C-R")   'backward-char)
C-h w backward-char correctly says it is on `C-r' (not `C-R').

And Control + Shift + `r' moves forward.

All of that is normal.  It is expected, since Control does not distinguish
uppercase and lowercase letters.  Control + Shift + lowercase-letter acts the
same as Control + lowercase-letter.  That is in the nature of Control.

But Meta does distinguish lowercase and uppercase letters.  Meta + Shift +
lowercase-letter does not necessarily act the same as Meta + lowercase-letter.

What is not so expected is this:

(global-set-key (kbd "M-R")   'backward-char)
(global-set-key (kbd "M-S-r") 'forward-char)
C-h w correctly tells us that these are on `M-R' and `M-S-r'.

Press Meta + Shift + `r'.  Point moves backward.

Whether (kbd "M-R") and (kbd "M-S-r") are `equal', and likewise
for `C-', is beside the point.

The point is that (kbd "M-S-r") binds a key that no one can ever type.  The only
recognized external representation for Meta + Shift + `r' is `M-R'.

Re: question about Meta + Shift modifiers: M-S-r and M-R

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> The point is that (kbd "M-S-r") binds a key that no one can ever type.

Just like S-r or foobar.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: question about Meta + Shift modifiers: M-S-r and M-R

[Drew Adams]

> > The point is that (kbd "M-S-r") binds a key that
> > no one can ever type.
> 
> Just like S-r

Yes, same problem.  I stand corrected that Meta is relevant here.

Same suggested fixes and workaround (`M-' removed from the quote):

> Either (a) have `kbd' or `define-key' reject such impossible key
> sequences or (b) allow `S-r' as an additional external
> representation (for `kbd') equivalent to `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.