| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Closes #6540
In #6221 there was a mistake in calculating which folds need to be
re-ordered. When there are no folds after those that have been adjusted,
then `move_end` remains 0. This results in reverse_fold_order()
swapping folds that have been adjusted with uninitialised folds in the
remainder of the grow array.
Add a check in foldMoveRange() to account for this case.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When foldUpdateIEMSRecurse() re-uses an existing fold, it misses the
case where the existing fold spans from before startlnum to after
firstlnum, the new fold does not span this range, and there is no
"forced start" of a fold. We add a case for this in.
Ensure that if there was no forced break in folds, we merge folds that
now touch each other.
Include testing for a tricky foldmethod=expr case that has never been a
bug. This case works at the moment because of some effects that are not
obvious when reading the code.
A test for this could be useful to ensure a regression doesn't happen.
vim-patch:8.0.0408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to re-order marks according to the :move command, do_move()
uses mark_adjust() in a non-standard manner. The non-standard action is
that it moves some marks *past* other marks. This doesn't matter for
marks, but mark_adjust() calls foldMarkAdjust() which simply changes
fold starts and lengths and doesn't have enough information to know that
other folds have to be checked and reordered.
The array of folds for each window are assumed to be in order of
increasing line number, and if this gets broken some folds can get
"lost".
There has been a previous patch to avoid this problem by deleting and
recalculating all folds in the window, but this comes at the cost of
closing all folds when executing :move, and doesn't cover the case of
manual folds.
This patch adds a new function foldMoveRange() specifically for the
:move command that handles reordering folds as well as simply moving
them. Additionally, we allow calling mark_adjust_nofold() that does the
same as mark_adjust() but doesn't affect any fold array.
Calling mark_adjust_nofold() should be done in the same manner as
calling mark_adjust(), but according changes to the fold arrays must be
done seperately by the calling function.
vim-patch:8.0.0457
vim-patch:8.0.0459
vim-patch:8.0.0461
vim-patch:8.0.0465
|
|
|
Fix a problem when filtering manually folded lines
When foldMarkAdjustRecurse() is called to adjust folds that start inside
the range of lines that are being moved and end outside that range, it
calculates `amount_after` for its recursive call incorrectly.
The calculation assumes that folds inside the changed range are being
deleted, but this is not always the case.
This means nested folds that start after the changed range of lines are
shifted an incorrect amount.
We fix this by calculating the `amount_after` differently if the folds
inside the changed range are not being deleted.
|
