GNU bug report logs - #10642
xt-mouse: Support extended coordinates

Previous Next

Package: emacs;

Reported by: Egmont Koblinger <egmont <at> gmail.com>

Date: Sun, 29 Jan 2012 19:30:02 UTC

Severity: normal

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10642 in the body.
You can then email your comments to 10642 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#10642; Package emacs. (Sun, 29 Jan 2012 19:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Egmont Koblinger <egmont <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 29 Jan 2012 19:30:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Egmont Koblinger <egmont <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: xt-mouse: Support extended coordinates
Date: Sun, 29 Jan 2012 17:27:43 +0100
[Message part 1 (text/plain, inline)]
Hi,

When running in terminal, Emacs only supports mouse clicks up to column or
row 223, due to a limitation in the original mouse protocol. However, there
is an extension (well, unfortunately, there are a couple of extensions) to
overcome this limit.

This request is hereby for emacs to implement one of them, so that mouse
click works on arbitrary coordinates.

The first of such extensions, implemented originally by xterm, is the
"1005" mode.  It is horribly broken, it breaks mouse handling of
applications that implement this extension but run on a terminal that
doesn't.  So long story short: please don't even consider implementing this
mode.

The next such extension, to overcome some problems with this mode was
implemented originall by rxvt-unicode, is the "1015" extension.  Currently
it is supported by quite a few terminal emulators, namely rxvt-unicode
9.10, iterm2 1.0 (added by mainstream author), xterm 277, gnome-terminal
(vte 0.31) and konsole git HEAD (to become 4.9) -- for the last three the
support was added by me.

For technical details about these two extensions, see the first comment of
http://www.midnight-commander.org/ticket/2662 .

Since writing that ticket, another extension, the "1006" mode was invented
by xterm's author, appeared in xterm-277, see the source of that for
details.  In spirit it's pretty much like 1015 (e.g. avoid binary and
spells out coordinates in decimal) but addresses some issues with 1015.

For some discussions about this 1006 extension versus 1015, see
http://vim.1045645.n5.nabble.com/Fwd-Mouse-reporting-and-new-standards-td3378370.html(warning:
multiple pages).

I am new to emacs's source and new to lisp, so probably I won't come up
with a patch myself.  However, looking at the code, I have a feeling that
adding support for 1006 might be easier than adding support for 1015.  This
is because 1006 begins with \e[< (and even though theoretically other
non-mouse events might also start with this escape, it's unlikely that
emacs will ever be interested in those), so in xt-mouse.el you can
define-key for \e[< and do all the rest in this file.  1015, due to lack of
a unique prefix, requires a quite different parsing flow, and the fix would
probably involve touching the C code, too.  That's my guess only.

Due to much wider adoptation by current terminals, I recommend that you
implement the 1015 extension if it's feasible.  If not, then please
implement the 1006 extension, and I'm happy to work in getting this
extension into as many terminal emulators as possible.

In either case, the good news is that no matter which of 1006 or 1015 you
choose, it won't break the behavior on terminals that don't support them.
Just ask the terminal to enable the extension by outputting
"\e[?1000h\e[?1015h" or "\e[?1000h\e[?1006h", disable similarly when
exiting (e.g. "\e[?1006l\e[?1000l").  If the underlying terminal supports
the extension, it will report coordinates in the new format, but if doesn't
then it will report coordinates in the old format.  These two formats are
distinguishable (except for the 1005 mode, that's why that extension is out
of question).

Just for the record: midnight commander >= 4.8.1 already supports the 1015
extension and autodetects it, no configuration is required from the user.
Vim >= 7.3.353 (>= 7.3.405 if running in xterm) also supports this
extension, but you need to have ":set ttymouse=urxvt" in your .vimrc, so
it's not autodetected; the autodetect possibility was discussed in the
thread linked above.

Let me know if there's anything I can help with (apart from writing the
actual patch :)).  The overall goal is hopefully to make clicks on
arbitrary positions just work out of the box, without the user having to do
anything.


thanks a lot,
egmont
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10642; Package emacs. (Sat, 14 Jul 2012 15:53:01 GMT) Full text and rfc822 format available.

Message #8 received at 10642 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Egmont Koblinger <egmont <at> gmail.com>
Cc: 10642 <at> debbugs.gnu.org
Subject: Re: bug#10642: xt-mouse: Support extended coordinates
Date: Sat, 14 Jul 2012 23:46:35 +0800
Egmont Koblinger <egmont <at> gmail.com> writes:

> When running in terminal, Emacs only supports mouse clicks up to
> column or row 223, due to a limitation in the original mouse protocol.
> However, there is an extension (well, unfortunately, there are a
> couple of extensions) to overcome this limit.
>
> This request is hereby for emacs to implement one of them, so that
> mouse click works on arbitrary coordinates.

Thanks; the detailed information in your report was very useful.  I've
implemented the 1006 protocol handling, and committed it to trunk.

The code assumes that if the terminal does not support 1006 mode,
sending the \e[?1006h sequence is a no-op, and mouse click events are
received using the old protocol.  We look for both \e[M and \e[< events
and handle them.  This seems to work on XTerms supporting 1006 mode
(tested with xterm-281) as well as older ttys (tested with xterm-271 and
xfce4-terminal 0.4.8).




bug closed, send any further explanations to 10642 <at> debbugs.gnu.org and Egmont Koblinger <egmont <at> gmail.com> Request was from Chong Yidong <cyd <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 14 Jul 2012 15:53:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10642; Package emacs. (Mon, 06 Aug 2012 20:48:02 GMT) Full text and rfc822 format available.

Message #13 received at 10642 <at> debbugs.gnu.org (full text, mbox):

From: Egmont Koblinger <egmont <at> gmail.com>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 10642 <at> debbugs.gnu.org
Subject: Re: bug#10642: xt-mouse: Support extended coordinates
Date: Mon, 6 Aug 2012 22:38:27 +0200
[Message part 1 (text/plain, inline)]
Thanks very much, Chong!

Just for the record, I've implemented the 1006 support to Gnome-Terminal
and Konsole; I hope they will accept my patches and this 1006 extension
will become quite mainstream across terminal emulators.

https://bugzilla.gnome.org/show_bug.cgi?id=681329
https://bugs.kde.org/show_bug.cgi?id=304686

thanks,
egmont

On Sat, Jul 14, 2012 at 5:46 PM, Chong Yidong <cyd <at> gnu.org> wrote:

> Egmont Koblinger <egmont <at> gmail.com> writes:
>
> > When running in terminal, Emacs only supports mouse clicks up to
> > column or row 223, due to a limitation in the original mouse protocol.
> > However, there is an extension (well, unfortunately, there are a
> > couple of extensions) to overcome this limit.
> >
> > This request is hereby for emacs to implement one of them, so that
> > mouse click works on arbitrary coordinates.
>
> Thanks; the detailed information in your report was very useful.  I've
> implemented the 1006 protocol handling, and committed it to trunk.
>
> The code assumes that if the terminal does not support 1006 mode,
> sending the \e[?1006h sequence is a no-op, and mouse click events are
> received using the old protocol.  We look for both \e[M and \e[< events
> and handle them.  This seems to work on XTerms supporting 1006 mode
> (tested with xterm-281) as well as older ttys (tested with xterm-271 and
> xfce4-terminal 0.4.8).
>
[Message part 2 (text/html, inline)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 04 Sep 2012 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 11 years and 247 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.