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]

[Charles_Davis]

      I hope that I can piggy-back on this thread to get a clue to the
problem I posted last week.  It seems germane, but I don't know enough to
know how it applies.

I cannot seem to get Emacs to recognize either the control or shift
modifiers for any of the arrow or 6-pack keys.  Only the meta-key modifier
seems to be recognized.  Is there some variable I need to set to make the
use of control and shift modifiers of these keys possible?

Thanks for the help.

Regards,
Charles Davis

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

[Kai Grossjohann]

Charles_Davis@fws.gov writes:

> I cannot seem to get Emacs to recognize either the control or shift
> modifiers for any of the arrow or 6-pack keys.  Only the meta-key modifier
> seems to be recognized.  Is there some variable I need to set to make the
> use of control and shift modifiers of these keys possible?

When you use a terminal, it sends escape sequences to the application
when you hit the cursor keys.  Many terminals send the same escape
sequence for, say, <left> and C-<left> and S-<left>.  So the
application (Emacs in this case) cannot distinguish them.

These days, terminals can be configured to send different escape
sequences for these cases.  Then you need to teach Emacs which escape
sequence stands for which keypress, and then you can bind these
keypresses normally.

Kai

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

[Charles_Davis]

Kai Grossjohann wrote:
> When you use a terminal, it sends escape sequences to the application
> when you hit the cursor keys.  Many terminals send the same escape
> sequence for, say, <left> and C-<left> and S-<left>.  So the
> application (Emacs in this case) cannot distinguish them.
> These days, terminals can be configured to send different escape
> sequences for these cases.  Then you need to teach Emacs which escape
> sequence stands for which keypress, and then you can bind these
>keypresses normally.
Kai

I am running Emacs from a BASH shell under CYGWIN.  I have tried changing
the terminal type from the default "cygwin" by doing

TERM=<term type>
export TERM

for 10-15 different terminal types.  Emacs seems to notice that I have
changed terminal type, for it changes the names of the keys.  However, in
every case, the control and shift modifiers are not noticed.

Can you suggest a terminal type for which these modifiers should work?

Thanks for the help.
Regards,
Charles




 Kai Grossjohann

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

[Kai Grossjohann]

Charles_Davis@fws.gov writes:

> Kai Grossjohann wrote:
>> When you use a terminal, it sends escape sequences to the application
>> when you hit the cursor keys.  Many terminals send the same escape
>> sequence for, say, <left> and C-<left> and S-<left>.  So the
>> application (Emacs in this case) cannot distinguish them.
>> These days, terminals can be configured to send different escape
>> sequences for these cases.  Then you need to teach Emacs which escape
>> sequence stands for which keypress, and then you can bind these
>> keypresses normally.
>
> I have tried changing the terminal type from the default "cygwin" by
> doing [...]  for 10-15 different terminal types.  [...]
>
> Can you suggest a terminal type for which these modifiers should work?

I'm sorry, I think I neglected to say one important bit of
information:

No terminal I know of comes preconfigured to support C- and S- for
function keys.

And by "configuring" the terminal I meant to use the built-in
configuration mechanism for the terminal in question so that it
changes its behavior.  For example, for the GNU/Linux console you can
define keymaps and load them with "loadkeys".  (There are predefined
maps "emacs" and "emacs2", perhaps one of them supports more modifiers
on function keys.)  As another example, the X11 program xterm can also
be configured through X resources to send different escape sequences.

But you're using Cygwin.  I think Cygwin normally comes with a version
of rxvt and invokes that for the bash.  I don't know whether rxvt can
be configured in the manner I described.  I also think that the Cygwin
bash can be invoked from within the normal command prompt window, but
I have no idea how to configure that program's keymap.

Sorry about the bad news,
Kai

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

[Thomas Dickey]

Kai Grossjohann <kai@emptydomain.de> wrote:

> I'm sorry, I think I neglected to say one important bit of
> information:

sorry, but your posting is inaccurate.

> No terminal I know of comes preconfigured to support C- and S- for
> function keys.

other than xterm and rxvt.  It's built into both (though using different
escape sequences).

> And by "configuring" the terminal I meant to use the built-in
> configuration mechanism for the terminal in question so that it
> changes its behavior.  For example, for the GNU/Linux console you can
> define keymaps and load them with "loadkeys".  (There are predefined
> maps "emacs" and "emacs2", perhaps one of them supports more modifiers
> on function keys.)  As another example, the X11 program xterm can also
> be configured through X resources to send different escape sequences.

that part's true.

> But you're using Cygwin.  I think Cygwin normally comes with a version
> of rxvt and invokes that for the bash.  I don't know whether rxvt can

and xterm of course.

> be configured in the manner I described.  I also think that the Cygwin
> bash can be invoked from within the normal command prompt window, but
> I have no idea how to configure that program's keymap.

up-to-date terminal descriptions are at

	ftp://invisible-island.net/ncurses/terminfo.src.gz

> Sorry about the bad news,
> Kai

xterm supports ANSI color, VT220 emulation and UTF-8
There's an faq at
	http://invisible-island.net/xterm/xterm.faq.html
	ftp://invisible-island.net/xterm/

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

[Kai Grossjohann]

Thomas Dickey <dickey@saltmine.radix.net> writes:

> Kai Grossjohann <kai@emptydomain.de> wrote:
>
>> I'm sorry, I think I neglected to say one important bit of
>> information:
>
> sorry, but your posting is inaccurate.
>
>> No terminal I know of comes preconfigured to support C- and S- for
>> function keys.
>
> other than xterm and rxvt.  It's built into both (though using different
> escape sequences).

Cool!

Thanks for setting me straight.

Kai

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

[Alan Mackenzie]

Charles_Davis@fws.gov wrote on Wed, 8 Sep 2004 12:08:35 -0400:

> I cannot seem to get Emacs to recognize either the control or shift
> modifiers for any of the arrow or 6-pack keys.  Only the meta-key
> modifier seems to be recognized.  Is there some variable I need to set
> to make the use of control and shift modifiers of these keys possible?

What Emacs version are you running (M-x emacs-version)?
What operating system are you running it on?
What windowing system or terminal/console are you running it on?

The solution, if any, to your problem is bound up with the answers to
these three questions.  About six years ago I had this problem with Emacs
20.2 on the console on Linux 2.0.35, but got it solved.

> Thanks for the help.

> Regards,
> Charles Davis

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

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

[Luc Teirlinck]

Charles Davis wrote:
    
    I cannot seem to get Emacs to recognize either the control or shift
    modifiers for any of the arrow or 6-pack keys.  Only the meta-key
    modifier seems to be recognized.  Is there some variable I need to set
    to make the use of control and shift modifiers of these keys possible?

I responded about the Control modifiers earlier.  Shift modifiers of
these keys are likewise simply ignored unless you are directly
communicating with a window system.  Also, unless you are directly
communicating with a window system, Shift-TAB is the same as TAB, C-A
is the same as C-a and so on.  Again, the only solution I know of is
to only use such bindings for window manager bindings and other
bindings that only make sense when directly communicating with a
window system.

Again, maybe other people know better solutions.

Sincerely,

Luc.

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

[Katsumi Yamaoka]

>>>>> In <mailman.1740.1094515688.1998.help-gnu-emacs@gnu.org>
>>>>>	Drew Adams wrote:

> How can I read the key sequence and obtain the modifier?

`M-x apropos RET modifier RET' will help. ;-)

(defun foo ()
  (interactive)
  (let ((event (read-event)))
    (message "modifiers: %s; key: %s"
	     (mapconcat 'symbol-name (event-modifiers event) ", ")
	     (event-basic-type event))))

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

[Drew Adams]

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

However, if you press Shift+[up] or Shift+[down], the message is [S-up] or
[S-down]. That seems correct to me.

Same thing with read-key-sequence as with read-key-sequence-vector.

Is this a bug?

I'm using Emacs 20.7.3 on Windows: (i386-*-nt5.1.2600) of Thu Dec 21 2000 on
buffy.

If I try this on Emacs 21 (21.3.50.1 - i386-mingw-nt5.1.2600 of 2004-04-27
on BERATUNG4), then the Shift modifier is lost on the S-up and S-down also.
Is this intended?

How can I read the key sequence and obtain the modifier?

Thanks,

  Drew

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

[Kai Grossjohann]

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

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

Kai

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