chrisbra / NrrwRgn

A Narrow Region Plugin for vim (like Emacs Narrow Region)
http://www.vim.org/scripts/script.php?script_id=3075
674 stars 25 forks source link

Region highlight is lost on write #87

Closed iamFIREcracker closed 2 years ago

iamFIREcracker commented 2 years ago

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.

chrisbra commented 2 years ago

I don't think this should happen. Hm, I am not using this plugin much anymore. Will have to debug this.

chrisbra commented 2 years ago

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.

iamFIREcracker commented 2 years ago

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:

  1. Line-wise selection, :NarrowRegion command
  2. Visual selection, <leader>nr mapping

Let's get now to the interesting part:

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...

chrisbra commented 2 years ago

thanks, I have included your change.