[vim/vim] All text is highlighted when starting a search with very magic when hlsearch and incsearch are active (#2337)

[Ram-Z]

When starting a new search none of the text is highlighted as expected. Then enable very magic (\v) and suddenly all text is highlighted. I'd expect this to behave the same way as starting a new search.

Steps to reproduce:

$ vim -N -u NONE -c "set hlsearch incsearch" /path/to/file

Then type:

/\v

Expected result: nothing is highlighted
Actual result: entire buffer is highlighted

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[Christian Brabandt]

See also this discussion on vim_dev: https://groups.google.com/forum/#!topic/vim_dev/J61pNy137Iw

I made a patch, that goes on top of the fix for #2292

Please see those two commits:

• chrisbra/vim@cc87161 (fixes #2292)
• chrisbra/vim@729c55e (fixes #2337, e.g. this issue mentioned here)

[Christian Brabandt]

Sorry there was an error. Here is an update:

See also this discussion on vim_dev: https://groups.google.com/forum/#!topic/vim_dev/J61pNy137Iw

I made a patch, that goes on top of the fix for #2292

Please see those two commits:

• chrisbra/vim@cc87161 (fixes #2292)
• chrisbra/vim@34535ea (fixes #2337, e.g. this issue mentioned here)

[haya14busa]

Awesome! Thanks @chrisbra!

I looked into the Vim source code before to fix this behavior, but I couldn't find how to fix it...

btw, will ^ or $ are highlighted? In incsearch.vim plugin, it suppress highlighting if the pattern is matched with zero width string, but it also turn off the highlight of ^ and $.

[Christian Brabandt]

btw, will ^ or $ are highlighted?

Interesting question. I was not sure, how is_zero_width would handle this. Trying it shows, that highlighting would be suppressed. I am unsure, whether this is correct or not.

[Bram Moolenaar]

Christian Brabandt wrote:

> > btw, will ^ or $ are highlighted?
>
> Interesting question. I was not sure, how is_zero_width would handle
> this. Trying it shows, that highlighting would be suppressed. I am
> unsure, whether this is correct or not.

Highlighting the "$" matches is useful at least. And then not
highlighting "^" would be unexpected.

We should really try to avoid highlighting everything, matching the
empty string. But other empy matches are likely to be useful.

--
Female engineers become irresistible at the age of consent and remain that
way until about thirty minutes after their clinical death. Longer if it's a
warm day.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

Okay will fix it.

[Christian Brabandt]

So how about the following commit:
chrisbra/vim@36e1a98

This works by checking from the start of the buffer whether the last typed pattern matches with zero-width (and again one position further, so that a pattern like \< or ^ can still be highlighted, while e.g. \zs won't be highlighted.) However this might potentially slow down Vim, because we have to do the check twice.

Here are some example patterns and some gotchas:

• \zs won't be highlighted
• \v won't be highlighted
• \< will be highlighted
• ^ will be highlighted
• $ will be highlighted
• \| won't be highlighted
• . will be highlighted
• \(foo\)\| will be highlighted

The last one might be surprising (and it is hard to fix), but I found it actually quite useful. Once you type a complex pattern and it suddenly highlights everything this gives some feedback that you either have made some error or are at a point in the pattern where it would match everything (and this shouldn't happen that often in practice to be really disturbing).

[Bram Moolenaar]

Christian wrote:

> So how about the following commit:

> https://github.com/chrisbra/vim/commit/36e1a98dd254a61dc4293cb3c71fc63d344edba8

>
> This works by checking from the start of the buffer whether the last typed pattern matches with zero-width (and again one position further, so that a pattern like `\<` or `^` can still be highlighted, while e.g. `\zs` won't be highlighted.) However this might potentially slow down Vim, because we have to do the check twice.
>
> Here are some example patterns and some gotchas:

> - `\zs` won't be highlighted
> - `\v` won't be highlighted
> - `\<` will be highlighted
> - `^` will be highlighted
> - `$` will be highlighted
> - `\|` won't be highlighted
> - `.` will be highlighted
> - `\(foo\)\|` will be highlighted

>
> The last one might be surprising (and it is hard to fix), but I found
> it actually quite useful. Once you type a complex pattern and it
> suddenly highlights everything this gives some feedback that you
> either have made some error or are at a point in the pattern where it
> would match everything (and this shouldn't happen that often in
> practice to be really disturbing).

Thanks for that overview. Now I wonder what problem we actually are
trying to solve.

I think we want to avoid highlighting everything while busy typing a
pattern. But if we type a pattern and we want to see what it's going to
match, highlighting everything is useful, it shows mistakes.

How about this instead: We don't highlight the matches until after a
short delay, so it updates when the user pauses typing. Then you won't
get all kind of fast flickering, but you do get to see all the matches
after a short pause.

This also avoids any trickery trying to guess what should be highlighted
(and showing something else after pressing Enter).


--
Anyone who is capable of getting themselves made President should on no
account be allowed to do the job.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Christian Brabandt]

How about this instead: We don't highlight the matches until after a short delay, so it updates when the user pauses typing. Then you won't get all kind of fast flickering, but you do get to see all the matches after a short pause.

I am sorry, I don't know how to do this. You are not talking about the char_avail() function right? Because that is already used in the incsearch code.

[Bram Moolenaar]

Christian Brabandt wrote:

> > How about this instead: We don't highlight the matches until after a
> > short delay, so it updates when the user pauses typing. Then you
> > won't get all kind of fast flickering, but you do get to see all the
> > matches after a short pause.
>
> I am sorry, I don't know how to do this. You are not talking about the
> `char_avail()` function right? Because that is already used in the
> incsearch code.

I very recently added this for the terminal balloon in
check_due_timer(). That is probably the best place for it. Could
perhaps use 'updatetime', but that's overloaded already.

So, if the timer feature is present, set the "incsearch_redraw_due_set"
flag and store the time in "incsearch_redraw_due". Add code in
check_due_timer() to do the redrawing, similar to the "bevalexpr" code.
Let's see how this works with half a second delay.

Without the timer feature I suppose we'll just keep it as-is, redraw
right away.

Later we may want to generalise these internal timers. There probably
other things we want to add here.

--
How To Keep A Healthy Level Of Insanity:
9. As often as possible, skip rather than walk.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Christian Brabandt]

is this still relevant? I have been looking into this issue again and I am wondering, if this is still relevant and needs a patch or we should close it. There is the empty_pattern() function now included with commit 6621605 which should theoretically alleviate this problem.

[Christian Brabandt]

I have written a preliminary patch for using a timer for incsearch highlighting here chrisbra/vim@3b1b9cb

[Ram-Z]

This is significantly better with Included patches: 1-1415 (which includes 6621605). The whole buffer isn't highlighted anymore.

There is however still a small difference between / and /\v in that the current cursor position is highlighted in the latter when it isn't in the former.

I would consider this issue closed, but since @chrisbra still has a commit against this, I'll leave it up to him to close it.

[Christian Brabandt]

using my commit will change it how highlighting works when incsearch is set so much, that I would expect a couple of new issues coming in. However once you get used to that incsearch does not kick in immediately, but only after a small pause, it also makes sense. I leave this to Bram to decide whether we need this or not.

[Christian Brabandt]

I am closing this. The mentioned patch breaks too many tests, so the patch is probably not correct.

[Christian Brabandt]

Closed #2337.