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
