Closed iamFIREcracker closed 2 years ago
I don't think this should happen. Hm, I am not using this plugin much anymore. Will have to debug this.
Hm, I cannot seem to reproduce this? Can you please give exact steps how you create this narrowed window? Also perhaps some information on your environment may be relevant.
I did spend some time looking into this today, and here are my findings.
First off, here is the context of the .txt file I have used for testing:
Who does not love Lorem Ipsum?
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
While to create the narrowed regions I have tried with the following steps, and either one of them seem to trigger the bug:
:NarrowRegion
command<leader>nr
mappingLet's get now to the interesting part:
:WidenRegion
ends up getting calledwinnr
points to the ID of the current window, i.e. the ID of the window where the narrowed buffer is currently loadedorig_buf
instead to the ID of the buffer where the narrowed region was created from<sid>JumpToBufinTab
gets invoked which results in making the original window active (i.e. winnr()
is now equal to bufwinnr(orig_buf)
exe ':noa'. orig_win. 'wincmd w'
, but I am not sure what that is for, since JumpToBufinTab
already took care of focusing the "right" windowThen the narrowed region is widened accordingly, and highlights optionally reset - this is the guard being used:
" also, renew the highlighted region " only highlight, if we are in a different window " then where we started, else we might accidentally " set a match in the narrowed window (might happen if the " user typed Ctrl-W o in the narrowed window) if !(has_key(s:nrrw_rgn_lines[instn], 'single') || winnr != winnr())
But the thing is, winnr
will always be different from winnr()
(in my execution path at least) which means the "re-highlight" logic will never be executed.
Now, by the look of :help matchadd()
, the new highlight pattern gets defined for the current window; doesn't this suggest that t the original window (i.e. the one where the narrowed region was created from), be the active, at the time <sid>AddMatches
is invoked? (which should already be the case, thanks to the call to JumpToBufinTab
)
For fun, I tweaked the guard logic as follows, and now the narrowed region seems to get re-highlighted correctly after each call to :WidenRegion
:
@@ -1361,7 +1361,7 @@ fun! nrrwrgn#WidenRegion(force) abort "{{{1
" then where we started, else we might accidentally
" set a match in the narrowed window (might happen if the
" user typed Ctrl-W o in the narrowed window)
- if !(has_key(s:nrrw_rgn_lines[instn], 'single') || winnr != winnr())
+ if !(has_key(s:nrrw_rgn_lines[instn], 'single') || bufwinnr(orig_buf) != winnr())
call <sid>AddMatches(<sid>GeneratePattern(
\ s:nrrw_rgn_lines[instn].start[1:2],
\ s:nrrw_rgn_lines[instn].end[1:2],
@@ -1397,7 +1397,7 @@ fun! nrrwrgn#WidenRegion(force) abort "{{{1
" then where we started, else we might accidentally
" set a match in the narrowed window (might happen if the
" user typed Ctrl-W o in the narrowed window)
- if !(has_key(s:nrrw_rgn_lines[instn], 'single') || winnr != winnr())
+ if !(has_key(s:nrrw_rgn_lines[instn], 'single') || bufwinnr(orig_buf) != winnr())
call <sid>AddMatches(<sid>GeneratePattern(
\s:nrrw_rgn_lines[instn].start[1:2],
\s:nrrw_rgn_lines[instn].end[1:2],
Again, this seems to work, but I am not sure about all the other use cases that this change might have broken...
thanks, I have included your change.
I am not sure if this is the expected behavior or not, but whenever I
:write
or:update
the buffer in which the narrowed region is loaded, the highlight of the same region in the original buffer (i.e. the one where the narrowed region was created from), is lost. Maybe this has something to do with the way I am using this plugin / vim (I probably hit:write
more than I should), but somehow I was expecting the highlight to stay there until the narrow region buffer is closed.Am I using this wrong?
Thanks in advance, M.