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

[Stefan]

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

Under X11, if I do C-h k S-up, I get a hel buffer that starts with:

   <up> (translated from <S-up>) runs the command previous-line

so it tells you right there.  But it admittedly, doesn't show you that S-up
intermediate step when running on a terminal (and it doesn't show you the
ESC sequence either because RMS thought it would be confusing).

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

Read-key-sequence does not return "what the user pressed", because of things
like function-key-map, key-translation-map, input-methods, events and
modifiers dropped, ... and also because it has to decide "when is it
finished" and it does that based on the currently active keymaps.

If you want to see what the user presses, try something like read-event
or this-command-keys.  But on a terminal, this will not tell you S-up
either, instead you'll get the ESC sequence.

> 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)?

When do you stop?  After one key, two keys, three?


        Stefan