Add CurSearch highlight group #10133
Conversation
The aim of CurSearch is to let the user highlight the current match without having to resort to overcomplicated plugins to approximate this simple feature. Closes vim#2819
Codecov Report
@@ Coverage Diff @@
## master #10133 +/- ##
==========================================
- Coverage 81.97% 81.96% -0.01%
==========================================
Files 167 167
Lines 187824 187845 +21
Branches 42355 42360 +5
==========================================
+ Hits 153964 153976 +12
- Misses 21514 21524 +10
+ Partials 12346 12345 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
Personally, I think |
|
|
Well, I can include it, but I do notice some problems. It does not update when the cursor is moved, that is OK, but when then using CTRL-L the highlight disappears. |
|
Hmm, there are more problems. When putting text multiple matches can be highlighted with CurSearch. |
i think it is more useful if the highlight not update when cursor moved, it worked like a |
|
What is the rationale for linking We already have |
|
Just for reference, there is a parallel PR for Neovim, which had pretty much the same discussion (with the same conclusion). |
|
What is the rationale for linking `CurSearch` to `Search` by default
when it is supposed to stand out among matches highlighted with
`Search`?
We already have `IncSearch` that provides the exact same functionality
*during* a search, showing the current match among a sea of matches,
so it seems more appropriate than `Search`.
By linking CurSearch to Search it is backwards compatible. Also, it's
hard to think of a color that would work for everyone. IncSearch has a
different purpose.
Since CurSearch requires extra redrawing, it might actually be better to
not define CurSearch at all, and then the existence of CurSearch can be
used to decide whether the redrawing is needed. Even better would be to
compare the CurSearch and Search highlighting, and when they are equal
skip the redraw.
…--
CART DRIVER: Bring out your dead!
LARGE MAN: Here's one!
CART DRIVER: Ninepence.
BODY: I'm not dead!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
What does "backwards compatible" mean in this context? How is
I disagree, especially now that we have |
|
I think it means updating Vim does not change the behavior. |
That's weird, I tested this patch for a while and didn't notice this problem. Sorry about that.
I had implemented the redraw using
Indeed, I missed some redraw calls.
Weird, I don't see the highlighting disappear with Ctrl-L nor
As Braam already said, this change shall not be noticed by the user unless they (or their theme) explicitly define |
|
Romain Lafourcade wrote:
> By linking CurSearch to Search it is backwards compatible.
What does "backwards compatible" mean in this context?
That users who are not aware of the change get the same coloring as
before. I added the CurSearch in my setup, and it makes quite a
difference. Not sure if I like it or not, but currently bugs are
causing some bad behavior (may have several matches highlighted with
CurSearch).
How is `IncSearch`, which is not behind any `#ifdef` in the code and
is defined the same for both "light" and "dark" background less
"backwards compatible" than `Search`?
It inverts, that works for both light and dark.
> IncSearch has a different purpose.
I disagree, especially now that we have `<C-g>` and `<C-t>`, which act
like "live" `nN`. When searching for a word with `incsearch` and
`hlsearch` on, the match that is highlighted with `IncSearch` is the
"current match": the one where the cursor will be moved after we press
`<CR>`.
IncSearch is much more prominent (at least in the default setup), which
is OK if the user is busy typing the pattern, but too much after hitting
Enter.
…--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man. I'm sorry. Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
> Well, I can include it, but I do notice some problems. "n" does not
> update. Needs using SOME_VALID instead of VALID.
That's weird, I tested this patch for a while and didn't notice this
problem. Sorry about that.
I have fixed that already.
> Optimally we would only redraw lines with a matching search pattern.
I had implemented the redraw using `redrawWinline` but found too many
edge cases to handle wrt multiline matches.
Redrawing with VALID also doesn't work, since it only redraws text that
was changed. We need a variant of VALID that redraws text with a
highlight match.
> "?" does not update the highlight. Perhaps other search commands?
Indeed, I missed some redraw calls.
This should already be working now.
> It does not update when the cursor is moved, that is OK, but when
> then using CTRL-L the highlight disappears. That is a bit strange.
Weird, I don't see the highlighting disappear with Ctrl-L nor `:redraw`.
Only after moving the cursor.
What still isn't right is that a put command may result in two matches
being highlighted. In this message search for "Redrawing", this should
have one match at the start of the line highlighted with CurSearch.
Yank this line, move the cursor a few lines and use "p". Now there are
two matches highlighted with CurSearch.
…--
If all you have is a hammer, everything looks like a nail.
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich, comp.lang.c++
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
In this snippet, a part of the match is unexpectedly highlighted with vim9script
&hlsearch = true
highlight! link CurSearch IncSearch
highlight! link Search ErrorMsg
['abcdefg', 'hijk']->setline(1)
setreg('/', 'defg\nhij')
feedkeys('n')More specifically, the start of the second line: The issue disappears if we add Test: vim9script
&hlsearch = true
highlight! link Search ErrorMsg
highlight! link CurSearch IncSearch
['abcdefg', 'hijk']->setline(1)
setreg('/', 'defg\nhijk')
feedkeys('n')More generally, the issue (if it is one) is triggered on the last line of a multiline match, when the latter ends on a column whose index is lower than the one where the first line starts. |
Problem: CurSearch highlight does not work for multi-line match. Solution: Check cursor position before adjusting columns. (closes #10133)
…y spotted Problem: Current instance of last search pattern not easily spotted. Solution: Add CurSearch highlighting. (closes vim/vim#10133) vim/vim@a439938 This fixes CurSearch highlight for multiline match. Omit screen redrawing code because Nvim redraws CurSearch differently.
…y spotted Problem: Current instance of last search pattern not easily spotted. Solution: Add CurSearch highlighting. (closes vim/vim#10133) vim/vim@a439938 This fixes CurSearch highlight for multiline match. Omit screen redrawing code because Nvim redraws CurSearch differently.
…y spotted Problem: Current instance of last search pattern not easily spotted. Solution: Add CurSearch highlighting. (closes vim/vim#10133) vim/vim@a439938 This fixes CurSearch highlight for multiline match. Omit screen redrawing code because Nvim redraws CurSearch differently.
…y spotted Problem: Current instance of last search pattern not easily spotted. Solution: Add CurSearch highlighting. (closes vim/vim#10133) vim/vim@a439938 This fixes CurSearch highlight for multiline match. Omit screen redrawing code because Nvim redraws CurSearch differently.
…match Problem: CurSearch highlight does not work for multi-line match. Solution: Check cursor position before adjusting columns. (closes vim/vim#10133) vim/vim@693ccd1
…y spotted Problem: Current instance of last search pattern not easily spotted. Solution: Add CurSearch highlighting. (closes vim/vim#10133) vim/vim@a439938 This fixes CurSearch highlight for multiline match. Omit screen redrawing code because Nvim redraws CurSearch differently.
…match Problem: CurSearch highlight does not work for multi-line match. Solution: Check cursor position before adjusting columns. (closes vim/vim#10133) vim/vim@693ccd1
…y spotted Problem: Current instance of last search pattern not easily spotted. Solution: Add CurSearch highlighting. (closes vim/vim#10133) vim/vim@a439938 This fixes CurSearch highlight for multiline match. Omit screen redrawing code because Nvim redraws CurSearch differently.
…match Problem: CurSearch highlight does not work for multi-line match. Solution: Check cursor position before adjusting columns. (closes vim/vim#10133) vim/vim@693ccd1
The aim of CurSearch is to let the user highlight the current match
without having to resort to overcomplicated plugins to approximate this
simple feature.
Closes #2819