> Hi Thomas,
>
> I saw you applied the 1015 patch but I didn't see you coming up with 1006.
> I'm looking at it right now.
yes... I reworked some of the 1015 change to make it simpler to
extend,
and then implemented 1006. I also modified vttest so I could see it
run.
(xterm uses 1006 for the X10 and highlighting modes as well). When
I'd
done that, I satisfied my curiousity regarding urxvt 1015 in a non-
UTF-8
locale, and saw that it indeed did not work properly. (I agree that
making
it work in that case would have been more than a line of code).
Prior to your comment about luit, no one had pointed out a technical
issue with 1005 (and modifying luit to work around 1005 would be
time not well spent).
> Could you please tell whether "^[[<" is a unique prefix that is used only
> for mouse reporting, and hence it can even be put in terminfo descriptions
> next to "^[[M"? If it's the case then I'm super glad. If not, I'll
> propose coming up with a 4th (arghhh) extension...
I have a different plan for terminfo (I'll add a feature that lets
ncurses parse a
string, and use that for handling the different flavors). I was sort
of considering
that after 1005, but it wasn't urgent (and there's always something to
fix in
ncurses).
> The story is: I tried to patch support to some applications. MC and Joe
> already done; I was studying someone else's patch to Vim; and I also looked
> at Emacs. My experience is:
>
> Most of these applications only handle incoming escapes that don't have any
> parameters, mouse being the only exception. Their parsing code looks up a
> table or tree to recognize the escape and then they immediately know what
> escape they're facing. This table or tree contains "^[[M" for mouse. If
> this one is found, the escape lookup part has already done its job and the
> code responsible for handling mouse events simply reads three more bytes.
There was some discussion on this list a year or so ago which dealt
with this
general issue. I recall advising someone that it would be useful to
see CSI come
in (escape+"[" for instance) and collect the characters that could
comprise a
control sequence formatted according to the ANSI/ISO/ECMA rules.
Timeouts
or mismatches would handle things like a single escape character.
But I agree that modifying existing code can be hard.
> Current urxvt extension needs a completely different parsing logic, which
> means that for both MC and Joe my patch is extremely ugly: it handles 1015
> mode as a special case.
>
> For emacs I couldn't solve the problem (I could solve it with utterly ugly
> hacks), since the first part (recognizing the common mouse prefix) happens
> in C, while the second part (reading the coordinates and taking action) are
> in Lisp. For implementing the 1015 mode I'd have to cross this boundary in
> terrible ways.
>
> So the conclusion is: A unique prefix that's used solely for reporting
> extended mouse coordinates makes it very easy to add support to existing
> applications. The lack thereof might make it extremely hard.
Well I don't have any intention of adding function-keys that send
this.
There could be responses to control strings from an application (at
some point),
but vim's unlikely to send those control strings without some
discussion and
modification.
> I'd like to see an extension that fulfills this criterium, and I would also
> prefer rxvt-unicode's developer to say OK to this (I don't want him to say
> it's broken and come up with yet another one...) If these two are done,
> I'd be happy to duplicate all my work so far, and push terminal emulators
> and applications towards implementing 1006.
I'm curious what his response would be :-)
> thanks a lot,
> egmont
>
> On Sun, Jan 22, 2012 at 02:57, Thomas Dickey [via VIM] <
>
>
>
>
>
>
>
>
>
> ml-node+s1045645n5163573...@n5.nabble.com> wrote:
> > On Jan 21, 11:19 am, Bram Moolenaar <[hidden email]<http://user/SendEmail.jtp?type=node&node=5163573&i=0>>
> > 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).
>
> > --
> > 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, visithttp://www.vim.org/maillist.php
>
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
>
> >http://vim.1045645.n5.nabble.com/Fwd-Mouse-reporting-and-new-standard...
> > To unsubscribe from Fwd: Mouse reporting and new standards, click here<http://vim.1045645.n5.nabble.com/template/NamlServlet.jtp?macro=unsub...>
> > .
> > NAML<http://vim.1045645.n5.nabble.com/template/NamlServlet.jtp?macro=macro...>
>
> --
> View this message in context:http://vim.1045645.n5.nabble.com/Fwd-Mouse-reporting-and-new-standard...
> Sent from the Vim - General mailing list archive at Nabble.com.
--
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
No comments:
Post a Comment