Saturday, January 21, 2012

Re: Fwd: Mouse reporting and new standards

To make it more complicated, if FEAT_TERMRESPONSE is defined, then somehow lines 4022-4114 handle the "parsing" of the extended mouse coordinates up to the point while collecting the digits; and only when the sequence is complete then are lines 4247-4295 executed to parse it again.  If FEAT_TERMRESPONSE is off, then parsing happens with a different flow, then prefixes are also parsed by LL 4247-4295.

Complicated, not sure how much it was "designed to work" or just "happens to work" ;)

e.

On Sat, Jan 21, 2012 at 17:18, Egmont Koblinger <egmont@gmail.com> wrote:
Hi,

On Sat, Jan 21, 2012 at 14:20, Bram Moolenaar <Bram@moolenaar.net> wrote:


BTW: Looking at the urxvt mouse detection code, it looks like there is
danger of getting stuck on a broken input sequence, when a semicolon is
missing it does "return -1", which means it gets more characters.  If
the semicolon is any other non-digit character we loop forever.

Yes that looks fishy.  It should proceed in case of semicolon (or M), return -1 on NUL, and return 0 otherwise.

I'm also not sure what the rest of the code (LL 4274-4295) does, why it needs to find that 'M' once again and parse the mouse code again. But maybe it's just me.


e.


--
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: