search

mbbill / undotree

The undo history visualizer for VIM
http://www.vim.org/scripts/script.php?script_id=4177
BSD 3-Clause "New" or "Revised" License
3.94k stars 101 forks source link

Extra state created in vim undo tree if edit done with undotree window open #106

Open rparenzs opened 5 years ago

rparenzs commented 5 years ago

Hi, just something weird I noticed. Seems like a bug, unless you aren't supposed to edit with the undotree (ut) window open:

Test case: Start with a new buffer (the edit window) :UndotreeShow to show the ut window Back in the edit window, insert a string, say ‘aa’, and hit Esc

Watch in the ut window as two states are added to the vim undo tree, the expected one, then an extra empty state (no change) after it. Now you have to hit undo twice to undo the single change. If you were to do the same edit without the ut window open, there would only be one state added. That's the first problem.

Now if you hit 'u' to undo, nothing happens in the edit or ut windows, it's like they're frozen, until you move the cursor, after which everything happens at once. You would expect the ut window to show a change in the current state (the >< marker), and the edit window to show a change in the signs column, both of which do not happen until you move cursor (say with ‘h’). That's the second problem.

I tested this on the 32-bit vim (windows xp), on a clean vim (blank _vimrc, no other plugins), on vim 8.1.1605 (recent nightly version), and on the latest undotree.vim here, dated 03/13/19, as well as releases 6.0 and 5.0

mbbill commented 5 years ago

it looks really weird. since this plug-in never change the history, it only shows the history. So there really shouldn't be any difference in edit history when ut window is open or not. the second issue sounds like an auto command isn't working but that's not normal either. I can't repro both on my Mac but tomorrow let me try to grab a PC to have a try. Nowadays it's really hard to find an Windows XP though, or even a 32bit system.

rparenzs commented 5 years ago

Thanks for checking. I've in the past consistently reproduced vim bugs in win64, except for gui-related stuff, so I stopped checking. I'll try to manage that today.

In the meantime, I briefly checked the last released version of vim (8.1.1) instead of the nightly, and the bug is NOT there. Interesting. I will check the latest nightly today as well.

rparenzs commented 5 years ago

Ok, I checked and the problem is still there on the latest nightly (1933) for my old winxp-32: gvim_8.1.1933_x86_signed.exe (dated 08/27/19) I also got on a win10-64 box and saw the same thing with that nightly version (1933): gvim_8.1.1933_x64_signed.exe I didn't bother with the old released version vim8.1.1 on Win10-64, since I already know the problem isn't there for WinXP-32.

rparenzs commented 5 years ago

Ok, I went back and checked old builds (winxp-32) after the 8.1.1 release until I found the first failing one, #0258 (dated Aug 8, 2018): https://github.com/vim/vim-win32-installer/releases/tag/v8.1.0258 There is one patch in there that seems undo related: 8.1.0256: using setline() in TextChangedI splits undo Hope that helps.

mbbill commented 5 years ago

yeah, undotree do need setline() to change the content of undotree window. But it shouldn't affect the main window contents. looks like it's more of a VIM bug

beefeater7 commented 4 years ago

I also experience the problem on Windows 10, Neovim 0.5.