aboutsummaryrefslogtreecommitdiff
path: root/test/functional/normal/undo_spec.lua
Commit message (Collapse)AuthorAge
* test: reorg #15698Justin M. Keyes2021-09-17
| | | | | | | | | | | | | | | | | | | | Problem: Subdirectories like "visual", "insert", "normal" encourage people to separate *related* tests for no good reason. Typically the _mode_ is not the relevant topic of a test (and when it is, _then_ create an appropriate describe() or it()). Solution: - Delete the various `test/functional/<mode>/` subdirectories, move their tests to more meaningful topics. - Rename `…/normal/` to `…/editor/`. - Move or merge `…/visual/*` and `…/insert/*` tests into here where appropriate. - Rename `…/eval/` to `…/vimscript/`. - Move `…/viml/*` into here also. * test(reorg): insert/* => editor/mode_insert_spec.lua * test(reorg): cmdline/* => editor/mode_cmdline_spec.lua * test(reorg): eval core tests => eval_spec.lua
* functests: Replace execute with either command or feed_commandZyX2017-04-09
| | | | | | | | | | Hope this will make people using feed_command less likely: this hides bugs. Already found at least two: 1. msgpackparse() will show internal error: hash_add() in case of duplicate keys, though it will still work correctly. Currently silenced. 2. ttimeoutlen was spelled incorrectly, resulting in option not being set when expected. Test was still functioning somehow though. Currently fixed.
* undo: :earlier, g-: Set b_u_seq_cur correctly. (#6016)Matthew Malcomson2017-01-31
Previously alternate branches were not accounted for properly, with this change g- after an undo to a branch point works. The current sequence number b_u_seq_cur is used in undo_time(), in u_doit() this was calculated by subtracting one from the curhead sequence number. The curhead header entry represents the change that was just undone, so the sequence number we want is that of the change we have moved to. This is the sequence number of the undo head that is the uh_next element of this curhead. That sequence number is not always one less than the curhead sequence number -- there may have been an alternate branch at this point. Instead of subtracting one, we now directly find the sequence number of curhead->uh_next.