This is the mail archive of the
mailing list for the Cygwin project.
Re: mintty and modifier keys
- From: Andy Koppe <andy dot koppe at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 19 Jul 2012 20:06:32 +0100
- Subject: Re: mintty and modifier keys
- References: <500829BD.email@example.com>
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
> 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?
See also this on how those keycodes could be put to use in the stty 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 ; I was surprised to find that mintty can already
> distinguish some key presses that xterm can't)
>  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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple