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

Thanks very much for explaining all that.

Andy

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