On Sun, Jan 22, 2012 at 15:40, dickey <dickey@his.com> wrote:
Thomas, 1005 has a much more significant issue than the luit one, as described in the first comment of http://www.midnight-commander.org/ticket/2662 . I guess I've already pointed you to this but you seem to have overlooked. Copy-pasting from there:
I'm also keen on forgetting 1015, as 1006 is obviously superior to both. However, there's still one drawback of 1006, which is the lack of unique prefix, which makes it hard to patch it to existing application. Although as long as the application is not interested in any other escape beginning with \e[< it's not that bad, definitely better than 1015 ;)
egmont
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).
Thomas, 1005 has a much more significant issue than the luit one, as described in the first comment of http://www.midnight-commander.org/ticket/2662 . I guess I've already pointed you to this but you seem to have overlooked. Copy-pasting from there:
- There is no way for an application to tell whether the underlying terminal supports this new mode (whether DECSET 1005 did actually change the behavior or not), but depending on this a completely different user action might generate the same input. Example:
- If the terminal doesn't support this extension, then clicking at (162, 129) generates \e[M<32><194><161>
- If the terminal supports this extension, then clicking at (129, 1) [bit of math: 129+32 = 161, U+0161 in UTF-8 is 194 161] generates \e[M<32><194><161><33>
- so there's no way to tell whether the terminal ignored the 1005 escape sequence, the user clicked on (162, 129) and then typed an exclamation mark; or whether the terminal recognized the escape, and the user clicked on (129, 1).
- Due to this horrible brokenness, there's no way to implement support it without explicitly asking the user (via a setting) if the terminal can speak this extension.
I'm also keen on forgetting 1015, as 1006 is obviously superior to both. However, there's still one drawback of 1006, which is the lack of unique prefix, which makes it hard to patch it to existing application. Although as long as the application is not interested in any other escape beginning with \e[< it's not that bad, definitely better than 1015 ;)
egmont
I have a different plan for terminfo (I'll add a feature that lets
> 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...
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).
There was some discussion on this list a year or so ago which dealt
> 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.
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.
Well I don't have any intention of adding function-keys that send
> 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.
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'm curious what his response would be :-)
> 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.
> ml-node+s1045645n5163573...@n5.nabble.com> wrote:
> thanks a lot,
> egmont
>
> On Sun, Jan 22, 2012 at 02:57, Thomas Dickey [via VIM] <
>
>
>
>
>
>
>
>
>
> > On Jan 21, 11:19 am, Bram Moolenaar <[hidden email]<http://user/SendEmail.jtp?type=node&node=5163573&i=0>>
> > wrote:> > > >http://www.midnight-commander.org/ticket/2662--please see that, and
> > > Egmont Koblinger wrote:
> > > > I think all your technical questions are answered in the first comment
> > of
> > ------------------------------> > 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> >http://vim.1045645.n5.nabble.com/Fwd-Mouse-reporting-and-new-standard...
> > below:
>
> > 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
--
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