No signals in modifyOtherKeys mode

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable modifyOtherKeys mode
2. press Control-\ using AltGr (e.g. German keyboard)
3. maybe also just press Control-\ (cannot check)

What is the expected output? What do you see instead?
Expected: QUIT signal
Delivered: ESC sequence

Please use labels and text to provide additional information.
I'm not sure whether there should be an exception of modifyOtherKeys mode for 
signal-associated keys. Also xterm behaviour is weird here. For Control-AltGr-\ 
it still sends SIGQUIT, for another Ctrl-\ (remapped with xmodmap for testing) 
it doesn't.
It might make sense to override modifyOtherKeys for control keys associated 
with a signal but I don't know whether the terminal can determine at the 
back-end side of a pty whether the application at the front-end side has 
disabled or remapped signals...

Original issue reported on code.google.com by towom...@googlemail.com on 31 May 2011 at 10:36

[GoogleCodeExporter]

Looking at 'man xterm', this is suppposed to depend on the modifyOtherKeys 
level, i.e. control characters should still be sent for level 1, but not level 
2. Mintty does this for Ctrl+letter combinations, but not Ctrl+symbol 
combinations. Groan, as if the keyboard handling wasn't complicated enough 
already.

Xterm appears to simply ignore the modifyOtherKeys setting when AltGr is down. 
No idea whether that's on purpose.

Peeking at the termios wouldn't work for remote connections.

Original comment by andy.koppe on 1 Jun 2011 at 8:22

• Added labels: Difficulty-Medium

[GoogleCodeExporter]

I'm having another problem about ^\, regardless of the signal issue (I cannot 
recognize it at all).
Considering again, I think actually xterm is doing half-way the right thing; 
AltGr changes the meaning of a key, e.g. it turns 'ß' into '\' on a German 
keyboard.
Processing modifyOtherKeys should then apply to '\' and thus generate ^[[92;7u 
rather than ^[[223;7u. This would also be consistent with other applications of 
this mode, e.g. Control-Shift-. (where Shift-. is :) generates ^[[58;6u now 
(which I consider proper) and not ^[[46;6u.

(Maybe this should be a separate issue, and I vote for prio high (consistency 
issue))

Original comment by towom...@googlemail.com on 3 Jun 2011 at 1:39

[GoogleCodeExporter]

Original issue fixed in r1193,

The second issue needs addressing, and treating AltGr similarly to Shift there 
makes plenty of sense, but priority High it is not.

Original comment by andy.koppe on 6 Jun 2011 at 7:58

• Changed state: Fixed

[GoogleCodeExporter]

I've entered issue 272 for the request in comment 2.

Original comment by andy.koppe on 8 Jun 2011 at 7:26

• Added labels: Difficulty-Easy
• Removed labels: Difficulty-Medium

[GoogleCodeExporter]

Original comment by andy.koppe on 12 Jun 2011 at 7:32

• Changed state: Verified
• Added labels: Milestone-0.9.9

[GoogleCodeExporter]

Actually, this issue is rather obsolete since QUIT can still be sent with 
Control-Break (recently discoverd :/ ).
So I propose to close it (forked issue 272 not affected).

Original comment by towom...@googlemail.com on 9 Dec 2011 at 11:07

[GoogleCodeExporter]

I'd already fixed it in 0.9.9 anyway, so that control characters are still sent 
in modifyOtherKeys level 1, like in xterm. Haven't tested it again now though 
...

Original comment by andy.koppe on 9 Dec 2011 at 7:30