[vim/vim] 'incsearch': "\n" highlights the first char in the line below (#6693)

[lkintact]

To Reproduce
Detailed steps to reproduce the behavior:

1. Run gvim --clean
2. Execute :set incsearch
3. Put this text to the buffer

test
abc

4. Type /test\n. You should see something like this:
   
   Notice that a in abc is highlighted.

Expected behavior
a shouldn't be highlighted.

Environment

• Vim version 8.2.1424
• OS: Windows 10 Home 1803
• Terminal: GUI.

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

[Christian Brabandt]

I suppose highlighting the a is the only way to make sure that there is actually a line break. Without highlighting the first character on the line, it wouldn't be clear, that the search item spans more than a single line.

[lkintact]

I suppose highlighting the a is the only way to make sure that there is actually a line break.

Doesn't highlighting the space after test serve that purpose?
.

[Gary Johnson]

On 2020-08-12, Christian Brabandt wrote:
> I suppose highlighting the a is the only way to make sure that there is
> actually a line break. Without highlighting the first character on the line, it
> wouldn't be clear, that the search item spans more than a single line.

But with this highlighting, it's not clear that the first character
is not included in the search pattern.

Not being able to highlight the newline is an inconvenience;
highlighting that first character is wrong.

Regards,
Gary

[vim-dev ML]

[Christian Brabandt]

Doesn't highlighting the space after test serve that purpose?

How do you know, that this is actually the linefeed and not a trailing whitespace?

Not being able to highlight the newline is an inconvenience;
highlighting that first character is wrong.

Yeah, I suppose that is right. I am probably too used to the current behaviour.

—
You are receiving this because you commented.

[lkintact]

How do you know, that this is actually the linefeed and not a trailing whitespace?

There's probably no way with the settings in post 1, but you can set 'list' on for situations like that.

—
You are receiving this because you commented.

[lkintact]

Not being able to highlight the newline is an inconvenience;
highlighting that first character is wrong.

Yeah, I suppose that is right. I am probably too used to the current behaviour.

@chrisbra Sorry for specifically drawing your attention to this, but I just had another situation with gVim highlighting a char that's not part of a search pattern. So will the issue be fixed? If not, perhaps the current behaviour should be considered a feature and somehow described in the docs?

—
You are receiving this because you commented.

[Christian Brabandt]

I suppose this is an implementation default, that might be noticeable by users for this specific edge case. It might be better to document this behaviour. Can you suggest a doc patch (or where to document this peculiarity)?

—
You are receiving this because you commented.

[Bram Moolenaar]

There is something wrong here. The character after the line is highlighted to indicate including the line break, but the first character on the next line is also highlighted. Typing that character doesn't change the highlighted match, so that looks wrong.

—
You are receiving this because you commented.

[Christian Brabandt]

There is something wrong here. The character after the line is highlighted to indicate including the line break, but the first character on the next line is also highlighted. Typing that character doesn't change the highlighted match, so that looks wrong.

Are you sure? The behaviour on the screenshot is the incsearch behaviour, e.g. what is shown, while typing the search pattern. 'hlsearch' option is showing fine. I thought this behaviour has been like this for as long as I can remember and as a quick test I downloaded the oldest release from the github.com/vim/vim-win32-installer repository, which is gvim 7.4.1185. It shows exactly this behaviour.

I believe this is caused by the fact that when searching the cursor is put on the first character of the next line after the \n, so the window is highlighted including the first column of the following line.

—
You are receiving this because you commented.

[Bram Moolenaar]

Have a line end in "the word" and the next line start with "xxx".
Put the cursor on "the", start a search command with "/word" (don't hit Enter).
Now "word" is highlighted. Adding the two characters "\n" adds both highlighting to just after "word"
and also the first "x". That "x" should not have highlighted.
Now add "x" - nothing changes. This is where the "x" would also have been highlighed.
When adding another "x" we get the first two "x" highlighted, back to being OK.

—
You are receiving this because you commented.

[Christian Brabandt]

Yes, understood what you are saying (and what is wrong).
what I was trying to say was, that this must have been broken a long time ago, because I remember vim behaving this way for very long (and didn't even think this is a bug). Anyway, will have a look

—
You are receiving this because you commented.

[Christian Brabandt]

Closed #6693.

—
You are receiving this because you commented.

[Christian Brabandt]

fixed by 448465e

—
You are receiving this because you commented.