The following steps can reproduce the odd behaviour:
(you may firstly try this plugin
http://www.vim.org/scripts/script.php?script_id=4177 to monitor the undotree in
realtime)
1. Open Vim, which will initialize an empty new file.
2. Make some changes. Say, adding three new lines.
3. Now, the undotree() returns
{'seq_last': 3, 'entries': [{'seq': 1, 'time': 1346076709}, {'seq': 2, 'time':
1346076710},
{'seq': 3, 'time': 1346076711, 'newhead': 1}], 'time_cur': 1346076711,
'save_last': 0, 'sync
ed': 1, 'save_cur': 0, 'seq_cur': 3}
let me visualize this, we have a tree something like:
* >3< (0 seconds ago) <- newhead,seq_cur,seq_last
* 2 (1 second ago)
* 1 (2 seconds ago)
* 0 (Original)
4. Redo 3 times and return to the original version, that is seq 0.
5. Make some changes. Say, adding two new lines.
6. Now, the undotree() returns:
{'seq_last': 5, 'entries': [{'seq': 4, 'alt': [{'seq': 1, 'time': 1346077579},
{'seq': 2, 't
ime': 1346077581}, {'seq': 3, 'time': 1346077581}], 'time': 1346077585},
{'seq': 5, 'time':
1346077585, 'newhead': 1}], 'time_cur': 1346077585, 'save_last': 0, 'synced':
1, 'save_cur':
0, 'seq_cur': 5}
and we have this tree:
* >5< (0 seconds ago) <- seq_cur,newhead
* 4 (0 seconds ago)
| * 3 (4 seconds ago)
| * 2 (4 seconds ago)
| * 1 (6 seconds ago)
|/
* 0 (Original)
7. Then, the most important step: undo twice. Then we should be at seq 0 and
nothing left in screen, which is the initial state of the new file. but, let's
see what undotree() returns:
{'seq_last': 5, 'entries': [{'curhead': 1, 'seq': 4, 'alt': [{'seq': 1, 'time':
1346077969},
{'seq': 2, 'time': 1346077971}, {'seq': 3, 'time': 1346077972}], 'time':
1346077974}, {'seq
': 5, 'time': 1346077974, 'newhead': 1}], 'time_cur': 1346077974, 'save_last':
0, 'synced':
1, 'save_cur': 0, 'seq_cur': 3}
seq_last:5, correct.
seq4 is the curhead, also correct because it's the next seq for redo.
seq_cur: 3, ???? shouldn't it be zero?
according to the doc, seq_cur should be "The sequence number of the current
position in the undo tree. This differs from "seq_last" when some changes were
undone.", but here it's obviously shouldn't be seq3.
Not finished yet.
8. Undo to seq 1 by
:undo 1
then undotree() returns
{'seq_last': 5, 'entries': [{'seq': 1, 'alt': [{'seq': 4, 'time': 1346077974},
{'seq': 5, 't
ime': 1346077974, 'newhead': 1}], 'time': 1346077969}, {'curhead': 1, 'seq': 2,
'time': 1346
077971}, {'seq': 3, 'time': 1346077972}], 'time_cur': 1346077969, 'save_last':
0, 'synced':
1, 'save_cur': 0, 'seq_cur': 1}
Then we have a tree like this:
* [5] (4 seconds ago) <- newhead
* 4 (4 seconds ago)
| * 3 (6 seconds ago)
| * {2} (7 seconds ago) <- curhead
| * >1< (9 seconds ago) <- seq_cur
|/
* 0 (Original)
Now, seq_cur is correct, BUT, the 'newhead' is incorrect. I think it should be
3 now, not 5, because it "Only appears in the item that is the last one that
was added. This marks the last change and where further changes will be added."
The description is quite obscure, let's go on the experiment.
9. Redo twice.
Now we got a tree like this:
* 5 (4 seconds ago)
* 4 (4 seconds ago)
| * >3< (6 seconds ago) <- newhead, seq_cur
| * 2 (7 seconds ago)
| * 1 (9 seconds ago)
|/
* 0 (Original)
and, undotree()
{'seq_last': 5, 'entries': [{'seq': 1, 'alt': [{'seq': 4, 'time': 1346077974},
{'seq': 5, 't
ime': 1346077974}], 'time': 1346077969}, {'seq': 2, 'time': 1346077971},
{'seq': 3, 'time':
1346077972, 'newhead': 1}], 'time_cur': 1346077972, 'save_last': 0, 'synced':
1, 'save_cur':
0, 'seq_cur': 3}
Everything is okay now, newhead become 3 again.
If you use undotree.vim to monitor the undo tree, you won't see the odd
behaviour for seq_cur because I found a workaround to find the correct seq (if
curhead exists, use its parent node, otherwise use seq_cur) , but you can still
see 'newhead' is sometimes wrong.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
