Add new "splice" interface for tracking buffer changes at the byte
level. This will later be reused for byte-resolution buffer updates.
(Implementation has been started, but using undocumented "_on_bytes"
option now as interface hasn't been finalized).
Use this interface to improve many edge cases of extmark adjustment.
Changed tests indicate previously incorrect behavior. Adding tests for
more edge cases will be follow-up work (overlaps on_bytes tests)
Don't consider creation/deletion of marks an undoable event by itself.
This behavior was never documented, and imposes complexity for little gain.
Add nvim__buf_add_decoration temporary API for direct access to the new
implementation. This should be refactored into a proper API for
decorations, probably involving a huge dict.
fixes#11598
Problem: In diff mode global operations can be very slow.
Solution: Do not call diff_redraw() many times, call it once when redrawing.
And also don't update folds multiple times.
4f57eefe1e
Problem: Ml_get error when deleting fold marker.
Solution: Check that the line number is not below the last line. Adjust the
fold when deleting the empty line. (Christian Brabandt,
closesvim/vim#4834)
9a4a8c4d59
vim-patch:8.0.0469: compiler warnings on MS-Windows
Problem: Compiler warnings on MS-Windows.
Solution: Add type casts. (Christian Brabandt)
0c0d4eca4d
vim-patch:8.0.0581: moving folded text is sometimes not correct
Problem: Moving folded text is sometimes not correct.
Solution: Bail out when "move_end" is zero. (Matthew Malcomson)
94be619e30
vim-patch:8.0.0583: fold test hangs on MS-Windows
Problem: Fold test hangs on MS-Windows.
Solution: Avoid overflow in compare.
b11c826ddc
Problem: ml_get errors in silent Ex mode. (Dominique Pelle)
Solution: Clear valid flags when setting the cursor. Set the topline when
not in full screen mode.
d5d37537d1
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.
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
