[ANNOUNCEMENT] Testing: mintty-0.9b2-1

[Ryan Johnson]

  On 9/28/2010 2:05 PM, Andy Koppe wrote:
> On 27 September 2010 17:02, Ryan Johnson wrote:
>> FYI, it looks like you can enable extended mouse mode manually (echo -ne
>> '\e[?1005h'), and it persists across normal mouse mode sessions.
> Does xterm do that differently? In that case I should change it.
I don't know. I submitted two patches, one of which resets extended mode 
every time the mouse mode changes. Thomas didn't tell me which one he 
ended up using. I didn't even know it was in xterm until I downloaded 
the mintty sources to try and hack them... and found the change already 
there with a comment about xterm-262.

To be honest, I like your way better (see below), even though it 
technically could theoretically break some apps under some circumstances.

>> This is
>> handy because
>> (a) emacs-23 can use it out of the box and
> Emacs has got support for that already? I'm positively surprised by
> that given the feature only went into xterm a month ago. (Well done
> for getting your patch into xterm, btw.)
Not quite :)

Emacs-23 treats all input as utf-8, so xterm's default mouse mode 
confuses it horribly by producing things that look like (in)valid utf-8. 
Any x-coordinate > 95 looks like the start of a multi-byte sequence 
which consumes the y, and y coordinates > 95 consume whatever character 
comes after the mouse click, hanging until such a character arrives. The 
worst part is that it's unpredictable whether emacs will get confused 
enough to just emit both characters, so there's no reliable way to 
reprocess the input to "fix" the problem (I tried...).

If xterm emits utf-8, emacs-23 suddenly "just works." Emacs-22 needs a 
small change to xt-mouse.el in order to convert the utf-8 sequences 
manually, but that's not hard at all if you know they're coming.

> I can't see a buffer wider than 223 columns being particularly useful,
> so I guess the main use is with split windows?
Exactly. Also, the emacs-23 utf-8 broken-ness kicks in at 95 columns, 
which is a reasonable size even for one buffer. That's actually what 
prompted the patch -- stray mouse clicks tended to dump random strings 
like "M#äé" into my code at arbitrary places, leading to frequent 
compile errors.

>> (b) it works around gnu screen intercepting and ignoring the escape sequence
> I suppose that's useful at sizes>95 already then?
Screen filters out the \e[?1005h sequence (and other unknown sequences, 
plus several known ones like the OSI sequences). This makes it 
impossible to activate extended mouse mode if, e.g., you run emacs 
inside screen. Screen also rewrites redundant sequences like 
"\e[?1000h\e[?1000h" to their minimal equivalent, so I couldn't even use 
a "port knocking" approach to get around it.

However, mintty lets you activate ext mouse mode before attaching 
screen, which works nicely around the problem. Given that screen's last 
release was about 4 years ago, this seems like a Good Thing to me...

(Ironically, I think it was some old version of screen which did the 
utf-8 encoding trick years ago and inspired my patch. I have a six year 
old .emacs from an hpux machine which had reverse-engineered the 
encoding without even knowing it was utf-8).

Regards,
Ryan


--
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