[vim/vim] DirDiff is broken after patch 8.1.2289 (#6042)
xdegaye
Describe the bug
The DirDiffNext command of the DirDiff plugin creates buffers that do not exist on the file system. git bisect says that this happened after patch 8.1.2289: after :diffsplit closing the window does not disable diff.
A mail refering to this issue is being sent to the DirDiff maintainer.
To Reproduce
Content of the /path_to_testdir directory:
$ cd /path_to_testdir; ls -R
.:
one/ two/
./one:
a b
./two:
a b
The content of file /path_to_testdir/two/a is AA. The content of the three other files is not relevant.
Run the following commands in the test directory (note that the call to DirDiffNext may be replaced by hitting the keys j and <Enter>:
:DirDiff one/ two/
:ls
1 %a- "/tmp/vnc0HK7/1" line 7
2 a "/path_to_testdir/two/a" line 0
3 a "/path_to_testdir/one/a" line 0
:DirDiffNext
:ls
1 a- "/tmp/vnc0HK7/1" line 7
2 %a- "/path_to_testdir/two/a" line 1
4 a "/b" line 0
5 a "AA/b" line 0
Problem: the new buffers 4 and 5 do not exist.
Environment (please complete the following information):
- All Vim versions after (and including) 8.1.228.
- Archlinux
- DirDiff version 1.1.4, i.e. the latest version.
Investigation
The problem does not occur when the call to set_diff_option() in ex_diffoff() at the HEAD of the vim master branch is commented out.
DirDiffNext parses the buffer of the top right window instead of the one in the bottom window. So it seems that either patch 8.1.2289 does not restore some context after calling ex_diffoff() or that the plugin makes some assumption that is not anymore valid after the patch.
Workaround
The following patch to dirdiff.vim prevents the call to ex_diffoff() and is a workaround (the plugin does not need the new closeoff option although it should be able to run with it).
diff --git a/dirdiff.vim b/dirdiff.vim
index b4a602e..03769e9 100644
--- a/dirdiff.vim
+++ b/dirdiff.vim
@@ -411,6 +411,7 @@ function! <SID>DirDiffOpen()
" Go back to the diff window
wincmd j
+ set diffopt=internal,filler
" Resize the window
exe("resize " . g:DirDiffWindowSize)
exe (b:currentDiff)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
xdegaye
Oups, s/DirDiff version 1.1.4/DirDiff version 1.1.5/ which is indeed the latest version.
Gary Johnson
> Oups, s/DirDiff version 1.1.4/DirDiff version 1.1.5/ which is
> indeed the latest version.
using Vim 8.2.587, and sourcing the plugin, version 1.1.5.
Interestingly, if I started Vim as just "vim", with all my
configuration, DirDiff behaved fine.
While the latest version on the Vim scripts page,
https://www.vim.org/scripts/script.php?script_id=102, is 1.1.5, that
page is no longer maintained. The plugin is now available only from
the GitHub repo at https://github.com/will133/vim-dirdiff. The
latest version is 1.1.6.
I didn't know all that until I started looking into this problem.
I discovered that my dirdiff plugin was out of date, so I updated to
the latest from the repo. I no longer see the problem.
Regards,
Gary
vim-dev ML
> Oups, s/DirDiff version 1.1.4/DirDiff version 1.1.5/ which is
> indeed the latest version.
I was able to reproduce the problem starting Vim as "vim --clean",
using Vim 8.2.587, and sourcing the plugin, version 1.1.5.
Interestingly, if I started Vim as just "vim", with all my
configuration, DirDiff behaved fine.
While the latest version on the Vim scripts page,
https://www.vim.org/scripts/script.php?script_id=102, is 1.1.5, that
page is no longer maintained. The plugin is now available only from
the GitHub repo at https://github.com/will133/vim-dirdiff. The
latest version is 1.1.6.
I didn't know all that until I started looking into this problem.
I discovered that my dirdiff plugin was out of date, so I updated to
the latest from the repo. I no longer see the problem.
Regards,
Gary
xdegaye
Christian Brabandt
I suppose it works also when the closeoff argument from the diffopt settings is removed? Having said that, I am not sure what you expect us to do here. As apparently the issue is also fixed in the dirdiff plugin, I tend to close this issue
—
You are receiving this because you commented.
xdegaye
I suppose it works also when the closeoff argument from the diffopt settings is removed?
It is indeed what is proposed in the workaround in the OP.
Not sure that this is fixed as issue will133/vim-dirdiff#27 is closed in DirDiff only because the problem does not occur anymore after an unrelated will133/vim-dirdiff@478c1a2 commit.
There is this french expression mostly used by developers that says tomber en marche (it is a reference to the tomber en panne common idiom that translates to to breakdown in english, tomber means to fall and en marche means working) and it means that something is working now but for no understandable reason. I would not call that a fix.
—
You are receiving this because you commented.
Tony Mechelynck
@xdegaye : sometimes a problem disappears for an unknown reason. On sites using the Bugzilla software to report and follow bugs and RFEs, it's the difference between RESOLVED FIXED (the problem has been identified, and the appropriate change has been implemented — the coffee machine had broken so it was repaired or replaced on such-and-such a day; or there was an error in the source and it was fixed at changeset abcd12349876fedc) and RESOLVED WORKSFORME (the problem does not happen anymore but we don't know why — maybe there was a race condition somewhere, and a refactoring of some apparently unrelated piece of code made the race condition disappear; or maybe the bug reporter switched to a faster machine and doesn't get hit by the problem anymore).
So we don't know what made the problem disappear, but as long as it doesn't come back we can't go hunting for it.
—
You are receiving this because you commented.