:s match highlighting does not respect the range restriction provided

[AdamTakvam]

Steps to reproduce

1. :50,100s/a/b/g # Replace every instance of 'a' with 'b' on lines 50 through 100
2. Observe 'a' is highlighted all over the document
3. Observe keyboards all over the world with premature wear on the :, n, o, and h keys.

You have the power to redeem these keys!

For some reason that is beyond my pay grade, the substitution function and hlsearch are like conjoined twins. Nonetheless, I'm certain that somehow POSIX has something to do with it because it always does.

On the surface, this marriage seems to be nothing more than a case of annoying and pointless behavior, but the fact that it is impacting lines outside of the given range is what elevates this to 'bug' status rather than simply 'annoyance.'

The really unfortunate part is that there might actually be some merit to this feature if it were written correctly to respect line ranges. Most of the time, users would not notice that highlighting was even happening because they just replaced the search word(s). But if the highlighting was seen, it would likely be useful as a reminder to verify that your substitution executed the way you wanted it to... or you probably forgot to use /g.

Expected behaviour

Highlighting should apply only within the specified substitution range (50–100).

Version of Vim

NVIM v0.10.4

Environment

OS: Debian 13.1 "Trixie"
Terminal: Windows Terminal -> ssh -> bash
Value of $TERM: xterm-256color
Shell: bash 5.2.37(1)-release

Logs and stack traces

N/A

[chrisbra]

Yes, highlighting using hlsearch as well as incsearch applies to the whole pattern wherever it matches. Any offsets or in this case address modifiers are not taken into account.. If your want it to highlight only specific lines, you'll need to use the /\%l regex atom.

NVIM v0.10.4

🙈

[clason]

Not even a half-way current Nvim release (up-to-date with Vim patches) smh. Sorry about that, didn't come from us.

[AdamTakvam]

Not even a half-way current Nvim release (up-to-date with Vim patches) smh. Sorry about that, didn't come from us.

It's the latest version in the Debian repo. I'm happy to install a newer version if you can point me to the repo or other instructions for how to do that.

[habamax]

It's the latest version in the Debian repo. I'm happy to install a newer version if you can point me to the repo or other instructions for how to do that.

To report issues here, you would need to provide repro steps using vim, not nvim.

[AdamTakvam]

It's the latest version in the Debian repo. I'm happy to install a newer version if you can point me to the repo or other instructions for how to do that.

To report issues here, you would need to provide repro steps using vim, not nvim.

Interesting. Can you elaborate on why that is? Did I file in the wrong place? I don't mean to be a nuisance; I'm usually rather helpful to have around once I get properly oriented.

[AdamTakvam]

It appears that I did misfile. My sincerest apologies. I did not recognize the rather sharp distinction between the Vim and Neovim codebases. I see now that Neovim is a completely different team. I'm terribly sorry to have wasted anyone's time.

[habamax]

It appears that I did misfile. My sincerest apologies. I did not recognize the rather sharp distinction between the Vim and Neovim codebases. I see now that Neovim is a completely different team. I'm terribly sorry to have wasted anyone's time.

No worries, vim behaves the same in this case and it is not considered as bug but expected behavior.

[AdamTakvam]

It appears that I did misfile. My sincerest apologies. I did not recognize the rather sharp distinction between the Vim and Neovim codebases. I see now that Neovim is a completely different team. I'm terribly sorry to have wasted anyone's time.

No worries, vim behaves the same in this case and it is not considered as bug but expected behavior.

I was 100% going to walk away, but then you had to say that. To which, I'm not going to argue since that would be pointless. You're going to do what you want. But I'll just review the unspoken rules of civil product management: When working on a codebase for which design documents have been lost - or perhaps never existed - it's not open season to just name any bug you don't want to fix a feature. Also, "expected behavior" is mealy-mouthed language. There's no such thing as "expected behavior". Software products have features. Features deliver coherent and demonstrable user value. Any deviation in observed product behavior from feature specification is a bug.

So...

If you want to call the existing behavior a feature - and you're well within your rights to do so - then it is incumbent upon you to thoroughly document that feature with reasonable justification provided in terms of what value that feature offers to your user base. In that way, you begin to grow a corpus of not only the what but also the why of what will eventually be a complete product description. With that, there is no question about what constitutes a bug vs a feature.

From a pragmatic perspective, I recommend a Wiki backed by git or some other product that will let you take snapshots corresponding to public releases.

Again, I don't know whether you guys are doing this or not. I would be delighted to be preaching to the choir. But it was time for my nightly finger workout anyway. ;-)

[ychin]

Yes, highlighting using hlsearch as well as incsearch applies to the whole pattern wherever it matches. Any offsets or in this case address modifiers are not taken into account.. If your want it to highlight only specific lines, you'll need to use the /\%l regex atom.

@chrisbra I don't think what you wrote is correct. The filed issue is talking about hlsearch here. The issue here is that after the :substitute command completes, the rest of the file is not littered with highlighted search pattern. It's as designed because the :substitute command stores the search pattern, and then Vim goes and highlight the pattern after the command is run. This is expected because we have no idea what the user wants afterwards with the pattern. They indicated they want the pattern to remain highlighted and they get it.

incsearch on the other hand works correctly and takes into account the address modifiers, because it's only used during the context of that search and it knows what the address modifiers are and will do the right thing. I think your updates in 3fc00c0 actually made the docs incorrect now.

I think what the user really wants is to immediately run :nohlsearch after a substitute command.

[AdamTakvam]

I think what the user really wants is to immediately run :nohlsearch after a substitute command.

I won't presume to speak for all users, but that seems like a very reasonable interpretation.