buffer_updates: set deleted_bytes correctly when hitting ~
#12646
Conversation
vigoux
force-pushed
the
ts-fix-tilde
branch
2 times, most recently
from
a6fdf8f
to
1a80857
Compare
vigoux
changed the title
deleted_bytes correctly when hitting ~
src/nvim/ops.c
Outdated
|
|
||
| line[lp.col] = (char_u)c; | ||
|
|
||
| ml_add_deleted_len(line, old_len); |
There was a problem hiding this comment.
I prefer to go for a purer style ml_add_deleted_len_buf
There was a problem hiding this comment.
the true in ml_get_buf(curbuf, lp.lnum, true) sets the line dirty so I suppose it should update statistics at some point. Maybe it happens too late ?
There was a problem hiding this comment.
After some digging, it seems (I may be wrong here) that the buf->deleted_bytes is not related to the fact that the line is dirty.
There was a problem hiding this comment.
Plus the name deleted_bytes is actually misleading, as this represent the old byte size for buffer updates.
I think that this old_byte_size should be computed just before sending the buffer update, in the extmarks code.
There was a problem hiding this comment.
since old_byte_size has to be lines anyway, shouldn't it be updated here https://github.com/neovim/neovim/blob/master/src/nvim/memline.c#L1879 instead ?
There are some other calls of ml_get_buf(_, _, true) that won't be taken care of otherwise (I could find examples throughout the code. This can be revisited in the bytetrack PR (maybe add it as a comment so that we don't forget).
Test this using treesitter highlighting, which is based on this old_byte_size.
This PR fixes #12645
The problem was the
deleted_bytesofbuf_tnot getting updated in thepbytesfunction, causing every feature relying on this to send wrong buffer updates (and by the same occasion making the treesitter tree out of sync).