diff options
| author | luukvbaal <luukvbaal@gmail.com> | 2026-02-16 15:35:53 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-02-16 09:35:53 -0500 |
| commit | a39334767321bf56dc6d0baedb048066fc56e11c (patch) | |
| tree | 5f2e87dd682fdba389a0bed72a9ffc4f8b1b0939 /runtime/lua/vim/range.lua | |
| parent | d131d67e67a8406fff2c3dc2f9a4aceb8ef36716 (diff) | |
| download | rneovim-a39334767321bf56dc6d0baedb048066fc56e11c.tar.gz rneovim-a39334767321bf56dc6d0baedb048066fc56e11c.tar.bz2 rneovim-a39334767321bf56dc6d0baedb048066fc56e11c.zip | |
fix(extmark): adjust invalidate range by one for deleted lines #37897
Problem: A multi-line extmark that ends exactly at a deleted range end
is not invalidated.
Revalidated sign mark is added with incorrect range.
Solution: Remove questionable invalidation range condition which was
originally added to avoid deleting a mark that ends below a
deleted line.
Since splicing for a deleted line, and a replaced range that
explicitly ends at column 0 beyond a deleted line is identical,
we can't try to distinguish these two cases. I.e. :1delete 1
and nvim_buf_set_text(0, 0, 0, 1, 0, {}) yield the same splice
operation.
This means that a multi-line sign_text mark should now span at
least one column beyond its end_row, as seen in the adjusted
test. This is still somewhat unexpected/inconvenient to me
which is what prompted me to try to avoid it with the original
condition.
Add revalidated sign mark back to decor with correct range;
third sign mark added to test exposed a crash.
Diffstat (limited to 'runtime/lua/vim/range.lua')
0 files changed, 0 insertions, 0 deletions