aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua/vim/range.lua
diff options
context:
space:
mode:
authorluukvbaal <luukvbaal@gmail.com>2026-02-16 15:35:53 +0100
committerGitHub <noreply@github.com>2026-02-16 09:35:53 -0500
commita39334767321bf56dc6d0baedb048066fc56e11c (patch)
tree5f2e87dd682fdba389a0bed72a9ffc4f8b1b0939 /runtime/lua/vim/range.lua
parentd131d67e67a8406fff2c3dc2f9a4aceb8ef36716 (diff)
downloadrneovim-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