[vim/vim] :s match highlighting does not respect the range restriction provided (Issue #18639)
Adam Takvam
AdamTakvam created an issue (vim/vim#18639)Steps to reproduce
- :50,100s/a/b/g # Replace every instance of 'a' with 'b' on lines 50 through 100
- Observe 'a' is highlighted all over the document
- 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
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18639)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
🙈
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #18639 as completed via 3fc00c0.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Clason
clason left a comment (vim/vim#18639)Not even a half-way current Nvim release (up-to-date with Vim patches) smh. Sorry about that, didn't come from us.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Adam Takvam
AdamTakvam left a comment (vim/vim#18639)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.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18639)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.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Adam Takvam
AdamTakvam left a comment (vim/vim#18639)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.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18639)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.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Adam Takvam
AdamTakvam left a comment (vim/vim#18639)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. ;-)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#18639)Yes, highlighting using
hlsearchas well asincsearchapplies 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/\%lregex 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.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Adam Takvam
AdamTakvam left a comment (vim/vim#18639)I think what the user really wants is to immediately run
:nohlsearchafter a substitute command.
I won't presume to speak for all users, but that seems like a very reasonable interpretation.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18639)Oh you are right. From reading the issue, it wasn't clear to me if the issue is with the highlighting applied during typing the :s command or the one that remains after it. In fact, 'hlsearch' already contains this part here:
Note that only the matching text is highlighted, any offsets are not applied.
But you are right, incsearch does adjust the highlighting for the address modifiers specified, so I was wrong here. I remembered differently.
@AdamTakvam try this here then please:
augroup myhlsearch
autocmd!
autocmd CmdlineEnter [:] :set hlsearch
autocmd CmdlineLeave [:] :set nohlsearch
augroup END
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Adam Takvam
AdamTakvam left a comment (vim/vim#18639)@chrisbra : When I first read your message, I had literally just an hour earlier finished cleaning up and porting my vim config into the new neovim lua-based syntax AND had treesitter happy and all of that. But I didn't want to let you down. That's when an angel of the lord floated in my window and whispered in my ear, "Use -u dumbass!". And so it was...
That's a clever little trick. It seems to work just as well in nvim as in vim currently. I'm going to tuck that one away (once I translate it to lua, that is... ugh)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.