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 <[email protected]> wrote: > Hi, > > On Sat, Jan 21, 2012 at 14:20, Bram Moolenaar <[email protected]> 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
