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

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

[Drew Adams]

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

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

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

[Drew Adams]

From: Stefan

> > Shouldn't code be able to read user input
> > without paying attention to key bindings?

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

Point taken.

What I really meant was wrt dropping the Shift modifier. Read-key-* has no
trouble knowing to stop after one key, if that key is undefined. For
example, if C-M-+ is undefined, it returns this: [-67108821]; it doesn't ask
itself when to stop.

Otherwise (a key sequence is defined), it continues to read until it gets
the complete key sequence. I would expect it to have such behavior all the
time, and not make an exception of Shift. That's all.

IMO:

 - read-key-* should not drop the Shift modifier: if Shift-* is undefined
and * is defined, it should act as it does with any other undefined key
sequence (return Shift-*), instead of returning *
 - if read-key-* does drop the Shift modifier, then this should be
documented
 - read-key-* should in any case optionally be able to not drop the Shift
modifier

  Drew

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

[Richard Stallman]

    2) Shouldn't it at least be documented in the doc strings of
    read-key-sequence and read-key-sequence-vector?

It already is:

The third (optional) arg DONT-DOWNCASE-LAST, if non-nil, means do not
convert the last event to lower case.  (Normally any upper case event
is converted to lower case if the original event is undefined and the lower
case equivalent is defined.)

    6) This is inconsistent (also) with read-event, which DTRT in this regard.

They are different for good reason.

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

That would be obviously inconvenient if the user rebinds such a key.

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

[Drew Adams]

Mea culpa.

It is documented in the doc strings, but I was misreading them. And I'm
happy that there is an option to these functions that cancels the Shift-drop
behavior.

I do think it would be clearer to specifically say that the Shift modifier
is dropped (unless DONT-DOWNCASE-LAST is non-nil), instead of saying that
"downcasing" is done. I may not be the only person who misreads this,
thinking that downcasing involves letters only.

That is, the notion of substituting lowercase for uppercase is different (to
me anyway) from the notion of dropping the Shift modifier. I don't think of
[S-left] as being uppercase and [left] as being lowercase. In fact, I don't
think those terms properly apply here: case is a property of letters, not
key sequences or keyboard keys.

The confusion is all the more likely given the only info I could find on
this in the Emacs Lisp manual:

 "If an input character is an upper-case letter and has no key binding,
  but its lower-case equivalent has one, then `read-key-sequence'
  converts the character to lower case."

It is not a matter of downcasing "upper-case letters".

Thanks,

  Drew

-----Original Message-----
From: Richard Stallman [mailto:rms@gnu.org]

    2) Shouldn't it at least be documented in the doc strings of
    read-key-sequence and read-key-sequence-vector?

It already is:

The third (optional) arg DONT-DOWNCASE-LAST, if non-nil, means do not
convert the last event to lower case.  (Normally any upper case event
is converted to lower case if the original event is undefined and the lower
case equivalent is defined.)