Re: Fwd: Mouse reporting and new standards

Hi Bram and others,

Returning to this old thread regarding mouse clicks beyond column 223...

Seems that xterm's 1006 extension is going to be the "winning" one, rather than urxvt's 1015 mode.  Almost all terminals that support any mouse coordinate extension do support this extension in their newest released or soon-to-be-released development versions.  Probably urxvt is the only exception, but it's always been a bit odd amongs emulators, and I hope the developer will include support one day.  This extension is also getting stronger on application side, e.g. Emacs-25 will support it too (only xterm's 1006 mode, not urxvt's 1015).

I see that someone was kind enough to already provide support for 1006 in Vim.

My only pet peeve is that the 1006 mode is not compiled in by default.  Trying to think from a user's point of view, this extension is not a feature, it's a bugfix (of a broken protocol).  With the default compile options, one can use mouse in the first 223 columns only - I doubt anyone would want this.  Having no mouse support at all might make sense, full mouse support sure does make sense, but something in between doesn't for me, still that's what one gets after a simple ./configure && make.

I think it would be great if people who have Vim with mouse support would be able to use it without limits, and without requiring to digging into configure options.

We're very close to that: all it would take is a one-line patch in feature.h, making FEAT_MOUSE_SGR guarded by FEAT_NORMAL.

If you agree that this is a bugfix and not an add-one feature, with minimal fingerprint in code size, and no risk at all (those terminals that don't support this extension will report old-fashioned codes and Vim will understand those too), then please consider making it a "normal" feature.  This way most people would have this working automagically.

Thanks a lot,
egmont

On Mon, Jan 23, 2012 at 11:01 AM, Thomas Dickey <dickey@his.com> wrote:

On Mon, Jan 23, 2012 at 09:21:50AM +0100, Egmont Koblinger wrote:
> On Mon, Jan 23, 2012 at 01:26, Thomas Dickey <dickey@his.com> wrote:
>
> >
> > I'd assume that one would start by doing a
> >
> >        (define-key input-decode-map "\e[<"
> > 'xterm-extended-mouse-translate))
> >
> > ...along with a suitable new function.  It's been a while since I
> > programmed in lisp, but it's usually readable.  Aside from
> > cut/paste/massage
> > of text already in the file, there's not much to lookup.
> >
>
> It's clear as long as mouse is the only event beginning with \e[< that's
> processed by Emacs.  As soon as there's a second, completely independent
> escape also beginning with \e[< which another module would like to process,
> problems begin.  Same happens with apparently many other applications.

I did mention that there's the potential for confusion already with the
X10 scheme.

> That being said, we can say that we stick to 1006, apps that are only
> interested in mouse-related \e[< codes can do the easy way of parsing, and
> apps that need to check for other \e[< codes need to do refactor more to
> implement a more correct parser.

sounds good.

--
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk8dL/QACgkQcCNT4PfkjttD2ACg1nFYSgNgEKr6YoIjq/hIofTy
mt0AnRgFD5UN4JHkXCjnOqshDmCF1+W9
=9ETo
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php