On 19 July 2012 16:37, Ryan Johnson wrote: > Hi all (mostly Andy), > > I notice that mintty 1.1 handles certain key combinations differently than > xterm: > > ctrl+enter produces 0x1e (RS) vs. CR in xterm > alt+enter produces ESC CR vs. nothing at all in xterm > > ctrl+shift+<letter> emits the unicode C2 control codepoints (0xc281 through > 0xc29a); xterm emits the C0 control value as if shift were unpressed. > > So, two questions: > 1. Is there a particular reason for this behavior?
Yes, I tried to make as many key combinations as reasonably possible available to applications without having to enable a special mode. I chose ^^ (0x1e) for Ctrl+Enter rather than a multi-character code so as to be able to use it in stty settings. Similarly, Ctrl+Backspace sends ^_ (0x1f). > Perhaps rxvt or some other non-xterm terminal emulator does it? Nope, they're mintty-specific. > 2. Is there documentation somewhere of what convention mintty follows for > the various special cases? Yep: http://code.google.com/p/mintty/wiki/Keycodes#Ctrl http://code.google.com/p/mintty/wiki/Keycodes#Special_keys See also this on how those keycodes could be put to use in the stty settings: http://code.google.com/p/mintty/wiki/Tips#Terminal_line_settings > (these questions are partly triggered by frustration at shift+enter not > working, which lead to me finding a reasonably sane proposal to fix these > kinds of terminal woes [1]; I was surprised to find that mintty can already > distinguish some key presses that xterm can't) > > [1] www.leonerd.org.uk/hacks/fixterms/ Hmm, that basically describes xterm's "modifyOtherKeys" mode, which mintty supports too. This can be enabled with the sequence "\e[>4;1m". (That's for level 1. There's also level 2, enabled with "\e[>4;2m", where the suggested CSI u keycodes are sent even for Ctrl+letter combinations.) Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
