Re: Fwd: Mouse reporting and new standards

On Sun, Jan 22, 2012 at 02:31:47PM +0100, Bram Moolenaar wrote:
>
> Thomas Dickey wrote:
>
> > On Jan 21, 11:19?am, Bram Moolenaar <B...@Moolenaar.net> wrote:
> > > Egmont Koblinger wrote:
> > > > I think all your technical questions are answered in the first comment of
> > > >http://www.midnight-commander.org/ticket/2662-- please see that, and of
> > > > course feel free to ask if you have any more questions.
> > >
> > > Thanks, that helps. ?However, it appears that the "second new extension"
> > > is not actually supported by xterm yet. ?Did Thomas Dickey say something
> > > about this?
> >
> > yes - in discussing this with Egmont a few months ago, I pointed out
> > some technical deficiencies with the 1015 code, and also noted a
> > problem with urvt's implementation of 1005 (if the locale encoding
> > isn't UTF-8, it won't report positions past 50x95).
> >
> > I followed up by implementing a 1006 which lacks the defects that I
> > noted in urxvt's design. Those points are summarized in the
> > change-log for #277, as well as in ctlseqs.
> > http://invisible-island.net/xterm/xterm.log.html#xterm_277
> > http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
> >
> > (Actually I made these changes at the beginning of December, but
> > other work got in the way of a more rapid update- hence the late
> > release for vttest to demonstrate the feature).
>
> I was searching for "urxvt" in the version logs, but it turns out it is
> called SGR 1006. That indeed looks like a more compatible mechanism.

This is the relevant section (more recent changes generally at the top):

* add SGR 1006, as a better technical solution than SGR 1015:
+ the responses will not be confused with line-deletion and
scrolling controls.
+ the button encoding is a little simpler, since it does not
add an unnecessary 32 because the integer parameter does not
have to be represented as a printable character.
+ the control responses for pressing and releasing a mouse
button differ, allowing an application to tell which button
was released.
Besides these improvements, in discussion, it was noted that
urxvt's implementation of 1005 is incorrect, relying upon a locale
that provides UTF-8 encoding. In contrast, vttest demonstrates a
correct decoding, independent of locale.
* add support for urxvt SGR 1015 to address shortcoming of SGR 1005
with luit (patch by Egmont Koblinger).

> So, if we first send DECSET 1005 and then send DECSET 1006 then,
> depending on the version of the terminal emulator, we keep getting the
> normal mouse codes or the new SGR 1006 mouse codes. We should be able
> to decode both.

That sounds right (though 1005 is not completely functional in urxvt,
as I noted).

> Note that in ctlseqs.html in the DECSET list 1006 and 1015 are not
> documented.

yes... I made a note about that earlier, but didn't remember to fix it
when closing out #277:

120108
forgot to document SGR 1005 and 1015 in the list of control sequences.
They _are_ documented in the mouse-specific stuff.

The #278 changes were closed out quickly because of the FreeBSD bug report.
At the moment, I've one "new" report which turns out to be at least a
couple of years old.

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