console enhancements: mouse events

[Thomas Wolff]

Corinna Vinschen schrieb:
>>>>  - Pressing something like Alt-ö on a German keyboard leaves an
>>>> illegal UTF-8     sequence (the second byte of the respective
>>>> sequence) in input, apparently     because Alt-0xC3 is handled
>>>> somehow. Don't know, though, whether this is     a cygwin
>>>> console issue or maybe a readline issue.
>>>>         
>>> Alt is converted to a leading ESC.  I don't know how to fix that for
>>> non-ASCII chars, yet.
>>>       
>> For non-ASCII it works fine, thanks to Andy for clarifying; I could
>>     
>
> Erm... sorry, but do we really talk about the same?  If you press
> Alt-ö, the console generates the sequence ESC 0xc3 0xb6.  That's not
> desired so I'm contemplating the idea to skip the keypress if the
> resulting multibyte char is > 1 byte.  This restricts ESC-somekey
> either to explicit function key sequences (ESC-[-foo, etc), or
> to just two byte sequences like ESC-A, ESC-0, ESC-;, etc.
>   
I had not expected you to take action on this issue so soon:
> - Don't create ESC sequences for ALT-key keypresses if key translates
>   into a multibyte sequence.  This avoids stray bytes in input when
>   pressing for instance ALT-ö (Umlaut-o) under UTF-8.
>   
- especially given:
> ...  And, whatever
> super-duper change we make to this essential console code in future,
> let's wait until after 1.7.1, please.
>   
Actually, I think this is the wrong change. I'm sorry I came up with 
this confusion because I didn't test sufficiently, but as I said in my 
second mail
> For non-ASCII it works fine,
and contemplating again
> If you press Alt-ö, the console generates the sequence ESC 0xc3 0xb6.
I think this is absolutely the right thing to generate - after all, what 
else should be expected here?
The "stray bytes" are created in bash/readline, the previous behavior of 
cygwin console in this case was perfect, I'd suggest to revert, please.

Thomas