RE: read-key-sequence(-vector) on Shift left/right gives[left]/[right], not [S-left]/[S-right] ?

["Drew Adams" <drew.adams@oracle.com>]

From: Kai Grossjohann:

> > (defun foo ()
> >  (interactive)
> >  (let ((foo (read-key-sequence-vector "" )))
> >  (message "foo: %s" foo)))
> >
> > Execute foo, press Shift+[left] or Shift+[right]. The message ([left] or
> > [right]) shows that the Shift modifier is lost.

> If S-<foo> is unbound, Emacs looks up the binding of <foo>.  So are
> S-<up> and S-<down> bound but S-<left> and S-<right> are unbound?

> The reason for this is such that you can use most keybindings even
> when caps lock is on.

------------8<-----------------------

Thanks, Kai. That was the answer I couldn't find (S-left/right weren't
bound).

However:

1) Where is this (perhaps handy but inconsistent/exceptional) behavior
documented? I haven't been able to find it in either the Emacs manual or the
Emacs Lisp manual. Perhaps this should be mentioned in the Emacs manual at
node Kinds of User Input?

2) Shouldn't it at least be documented in the doc strings of
read-key-sequence and read-key-sequence-vector? The doc string mentions that
button-down events are dropped, but it says nothing about dropping the shift
modifier. Are these two functions the only ones affected by this exceptional
convention?

3) The Emacs manual says, in node Window Handling Convenience Features and
Customization: "Not all terminals support shifted arrow keys". Without
knowing that the read-key-* functions drop the shift modifier if that key
sequence is currently unbound, someone could easily think that the terminal
just doesn't support shifted arrow keys. Convenience or confusion?

4) Is this really a good thing, anyway? If I want a command that reads key
sequences, should I really have to pre-bind (and later unbind, to clean up)
such "exceptional" keys, just to be able to read the input key sequence
correctly (to see what the user pressed)? At the least, shouldn't there be
an option in read-key-sequence and read-key-sequence-vector to _not_ ignore
the shift modifier?

5) What does key binding have to do with reading key input? Shouldn't code
be able to read user input without paying attention to key bindings (and
whether or not keys are bound)?

6) This is inconsistent (also) with read-event, which DTRT in this regard. I
guess that's what I would need to do in this case: read-event and then test
for modifiers. But that seems heavy-handed if what I really want to do is
just read a key sequence (read-key-sequence, read-key-sequence-vector).

7) If this is for the convenience of being able to use the keys with
caps-lock on, as the manual says, then why not just pre-bind shift-* to the
same binding as * (*= any key)? And let users know to do the same thing if
they rebind keys. The current approach seems like the wrong way to deal with
this.

Thanks,

  Drew