This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Testing: mintty-0.9b2-1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]