[ANNOUNCEMENT] Testing: mintty-0.9b2-1
Wed Sep 29 12:53:00 GMT 2010
On 28 September 2010 14:27, Ryan Johnson wrote:
> 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.
Looking at the xterm sources again, Thomas went for the one without
the reset. Phew.
>> 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
>> 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
> 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).
Thanks very much for explaining all that.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin