X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<4CA1ED50.5080706@ece.cmu.edu>
References:	<announce.AANLkTindZrB7ygm+ZK+z1SoMTSjJoh8k5wL0PPfzULq7 AT mail DOT gmail DOT com> <4CA0C01C DOT 1030508 AT ece DOT cmu DOT edu> <AANLkTimpUtqy-trcQwV0v0Nsos53xDiR-AQyKC8nsQwX AT mail DOT gmail DOT com> <4CA1ED50 DOT 5080706 AT ece DOT cmu DOT edu>
Date:	Wed, 29 Sep 2010 07:20:50 +0100
Message-ID:	<AANLkTi=DkoviebevuS9cSgjcOBDbpZUfoROS9xLkB6os@mail.gmail.com>
Subject:	Re: [ANNOUNCEMENT] Testing: mintty-0.9b2-1
From:	Andy Koppe <andy DOT koppe AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 28 September 2010 14:27, Ryan Johnson wrote:
> =C2=A0On 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 end=
ed
> 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 in=
put
> to "fix" the problem (I tried...).
>
> If xterm emits utf-8, emacs-23 suddenly "just works." Emacs-22 needs a sm=
all
> change to xt-mouse.el in order to convert the utf-8 sequences manually, b=
ut
> 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, whi=
ch
> is a reasonable size even for one buffer. That's actually what prompted t=
he
> patch -- stray mouse clicks tended to dump random strings like "M#=C3=A4=
=C3=A9" 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, p=
lus
> 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 mini=
mal
> equivalent, so I couldn't even use a "port knocking" approach to get arou=
nd
> it.
>
> However, mintty lets you activate ext mouse mode before attaching screen,
> which works nicely around the problem. Given that screen's last release w=
as
> 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 .em=
acs
> from an hpux machine which had reverse-engineered the encoding without ev=
en
> 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

- Raw text -