nvim_buf_set_text does not handle negative row numbers correctly: for
example,
nvim_buf_set_text(0, -2, 0, -1, 20, {"Hello", "world"})
should replace the 2nd to last line in the buffer with "Hello" and the
first 20 characters of the last line with "world". Instead, it reports
"start_row out of bounds". This happens because when negative line
numbers are used, they are incremented by one additional number to make
the non-negative line numbers end-exclusive. However, the line numbers
for nvim_buf_set_text should be end-inclusive.
In #15181 we handled this for nvim_buf_get_text by adding a new
parameter to `normalize_index`. We can solve the problem with
nvim_buf_set_text by simply availing ourselves of this new argument.
This is a breaking change, but makes the semantics of negative line
numbers much clearer and more obvious (as well as matching
nvim_buf_get_text).
BREAKING CHANGE: Existing usages of nvim_buf_set_text that use negative
line numbers will be off-by-one.
Update runtime files
944697ae19
Doc changes:
Include remote_*() (even though +clientserver and remote.txt isn't ported yet)
Omit screenpos() (need v8.2.4389)
Other changes are N/A or cannot be directly applied
nvim_buf_get_text is the mirror of nvim_buf_set_text. It differs from
nvim_buf_get_lines in that it allows retrieving only portions of lines.
While this can typically be done easily enough by API clients,
implementing this function provides symmetry between the get/set
text/lines APIs, and also provides a nice convenience that saves API
clients the work of having to slice the result of nvim_buf_get_lines
themselves.
Problem: getchar() may return modifiers if no character is available.
Solution: Do not process modifiers when there is no character. (closesvim/vim#9806)
ad6c45f625
“make clint-full” bypasses the normal mechanisms used to communicate
build flags in the CI jobs, so explicitly build nvim before running the
lint jobs.
Closes https://github.com/neovim/neovim/issues/17456
* treesitter uses the default highlight priority of 50
* diagnostic highlights have a priority of 150
* lsp reference highlights have a priority of 200
This ensures proper ordering.
Problem: Illegal memory access when using exactly 20 highlights.
Solution: Add one more item in the array. (Brandon Richardson,
closesvim/vim#9800)
a493b6506b
Problem: Crash when using special multi-byte character.
Solution: Don't use isalpha() for an arbitrary character.
5921aeb574
Rename vim_isalpha to mb_isalpha.
Problem: Integer overflow with large line number.
Solution: Check for overflow. (closesvim/vim#9202)
03725c5795
Put E1247 in globals.h as E1240 is also there.
Do not make getdigits() abort.
