GNOME Bugzilla – Bug 730157
add support for xterm's modifyOtherKeys bindings
Last modified: 2014-10-31 08:54:06 UTC
xterm with the modifyOtherKeys=2 option has key bindings for many key combinations that are not otherwise available in a terminal. Emacs is one applications that benefits from these key bindings, C-. C-S-left and other kinds of bindings work and can be used, there's very little difference between the key bindings available in X11 mode vs the ones available in terminal mode.
I guess then we'd need to support modifyOtherKeys=1 too. In xterm, the mode is enabled by echo -ne '\e[>4;2m' Probably the toughest part would be to exactly copy xterm's behavior. E.g. with US layout, Shift+1 sends a literal '!' character, while Shift+2 sends the escape sequence encoding Shift + 2 (^[[27;2;64~). Weird. Similar issues happen with AltGr+Shift non-US layouts where AltGr has a real purpose. We'd need to watch out for non-US layouts, accented characters (Latin-1 are encoded properly, non-Latin-1 are dropped when pressed with modifiers rather than sending the Unicode value(?!)), state of Caps Lock, etc... C-S-left can already be used in emacs without this mode, it already generates distinct escape sequence. C-. doesn't seem to be supported out of the box, so one would need such a terminal, plus hack around in emacs' configs, is that correct?
(In reply to comment #1) > C-S-left can already be used in emacs without this mode, it already generates > distinct escape sequence. Sorry, I misremembered, C-S-up and C-S-down do not have distinct sequences. > C-. doesn't seem to be supported out of the box, so > one would need such a terminal, plus hack around in emacs' configs, is that > correct? C-. is used by AucTex by default, so one would need to use that package to see it in use... These were just some examples of the top of my head, there are many more. I added support in emacs for these keys about 7 years ago...
Duplicate of 477068?
Indeed. *** This bug has been marked as a duplicate of bug 477068 ***