On Sun, Jan 22, 2012 at 02:31:47PM +0100, Bram Moolenaar wrote: > > Thomas Dickey wrote: > > > On Jan 21, 11:19?am, Bram Moolenaar <[email protected]> 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 <[email protected]>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
