On Thu, Nov 18, 2010 at 6:07 PM, Christian Brabandt <[email protected]> wrote: > Hi James! > > On Mo, 08 Nov 2010, James Vega wrote: > >> On Mon, Nov 8, 2010 at 3:34 PM, Christian Brabandt <[email protected]> >> wrote: >> > On Fr, 05 Nov 2010, Benjamin R. Haskell wrote: >> >> Removing the optionality, it's also weird, as the trailing space >> >> (singular!?) isn't matched: >> >> >> >> /\%V\S\+\s*\%V >> >> xxxxx VVV VVV VVV xxxxx - text >> >> mmmmmmmmmmmm - match >> >> xxxxx VVV xxxxx - text >> >> mmmm - match >> >> >> >> Can anyone shed some light on this? >> > This is a bug. The regular expression engine is quite complex in Vim. I >> > think, the attached patch fixes it. >> >> What I see with your patch is that end of the match is including the >> first non-whitespace character after the end of the whitespace sequence. >> This means all matches other than the first start on the second >> non-whitespace character in the \S sequence and if the last >> non-whitespace sequence is only one character, the subsequent whitespace >> sequence won't be matched. >> >> Using the style from above (with alternating case for 'm' indicating the >> distinct matches): >> >> xxxxx VVV VVV V xxxx - text >> mmmmmMMMM - match >> >> Also, I see inconsistent highlighting with 'incsearch' enabled when the >> user has typed part of an escape sequence (e.g., '\' or '\%'). The >> highlighting for every line below some arbitrary line completely >> disappears until the escape sequence is completed. Performing a >> ":redraw!" or "/<Up>" may also trigger this. >> >> If this happens while typing the search string, complete the escape >> sequence, backspace to make it incomplete, complete it, etc. You'll see >> the portion of the file that's properly syntax highlighted increase >> every time you change the (in)complete status of the escape sequence. >> >> Not sure if it's related, but the patch also introduces this warning: >> >> regexp.c: In function ‘regtry’: >> regexp.c:3741: warning: comparison between pointer and integer > > Here is another patch, including a basic test, that should address all > the issues. I couldn't reproduce the highlighting problem, though. This > seems to work ok for me now for the test cases I could imagine.
This does seem to work better. I'm still seeing the highlighting corruption with "set hls is". I seem to have found another problem the patch introduces, though, as well as one that exists without the patch. Here's the introduced problem: $ printf "foo\nbar\n" > testfile $ vim -u NONE -N --cmd 'set hls' testfile " Set the visual block to contain both lines and place the cursor " just after 'bar' on the second line <C-v>j$<Esc> " Search for the test pattern, note that the cursor doesn't move off " the r /\%V\S\+\s*\%V " Attempt to jump to the next match of the pattern, cursor still " doesn't move n For some reason, with the patch the r is trapping the cursor. If you move the cursor to the start of the file, and use n to cycle through the matches, you'll correctly land on the 'f' and 'b' and then jump to the 'r' and get stuck there. If you cycle backwards with N, the cursor won't get stuck but it does see the 'r' as a valid match. As for the existing problem that I discovered, use the same test file. Visually select only the foo line and perform the search. Now visually select only the bar line. Both foo and bar will be highlighted until a redraw is forced (via either <C-l> or :redraw!). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[email protected]> -- You received this message from the "vim_dev" 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
