Repository navigation
bug: tests fail with neovim v0.12.4 #891
Description
Neovim version (nvim -v)
v0.12.4
Operating system/version
Debian
Read debugging tips
- I have read through the debugging tips.
Add the debug logs
- I have set
log_level = vim.log.levels.DEBUGand pasted the log contents below.
Log file
runner_spec failure
56s Fail || runner e2e sets the correct output
56s ...c.nu_69dua/downtmp/autopkgtest_tmp/tests/runner_spec.lua:211: Expected objects to be the same.
56s Passed in:
56s (table: 0x7ff64618af30) {
56s [1] = 'hello' }
56s Expected:
56s (table: 0x7ff6461c3730) {
56s [1] = 'hello'
56s *[2] = '' }
56s
56s stack traceback:
56s ...c.nu_69dua/downtmp/autopkgtest_tmp/tests/runner_spec.lua:211: in function 'run_formatter_test'
56s ...c.nu_69dua/downtmp/autopkgtest_tmp/tests/runner_spec.lua:264: in function <...c.nu_69dua/downtmp/autopkgtest_tmp/tests/runner_spec.lua:214>
fuzzer_spec failure
56s Fail || fuzzer formats correctly
56s ...c.nu_69dua/downtmp/autopkgtest_tmp/tests/fuzzer_spec.lua:29: Expected objects to be the same.
56s Passed in:
56s (table: 0x7fb8ebf24748) {
56s [1] = 'onbcqeik kuufbfwrd obkaycu'
56s [2] = 'oknhjmnsxw cztbuvu bybciw'
56s [3] = ''
56s [4] = 'bxfkryl euo mervzmod esf kioe'
56s [5] = 'abzodw' }
56s Expected:
56s (table: 0x7fb8ebf2d358) {
56s [1] = 'onbcqeik kuufbfwrd obkaycu'
56s [2] = 'oknhjmnsxw cztbuvu bybciw'
56s [3] = ''
56s [4] = 'bxfkryl euo mervzmod esf kioe'
56s [5] = 'abzodw'
56s *[6] = '' }
56s
56s stack traceback:
56s ...c.nu_69dua/downtmp/autopkgtest_tmp/tests/fuzzer_spec.lua:29: in function 'run_formatter'
56s ...c.nu_69dua/downtmp/autopkgtest_tmp/tests/fuzzer_spec.lua:127: in function <...c.nu_69dua/downtmp/autopkgtest_tmp/tests/fuzzer_spec.lua:120>
Describe the bug
neovim/neovim#40176 changed the behavior of apply_text_edits, apparently fixing a bug that's existed since 0.8.0. This causes a couple tests to fail since there is now an unexpected newline at the end of the buffer.
What is the severity of this bug?
breaking (some functionality is broken)
Steps To Reproduce
Run test suite with nvim 0.12.4 or master.
Expected Behavior
Test suite passes
Minimal example file
No response
Minimal init.lua
No response
Additional context
No response
Activity
nfvelten commentedon Aug 31, 2026
Hit this on 0.12.5 too, and I think the test is right and the bug is real.
Narrowed it down by bisecting the pieces between 0.11.7 and 0.12.5.
vim.bo.eolistrueon both,vim.systemreturns the same"hello\n\n"on both, andvim.diffandvim.text.diffboth return{{1,0,2,1}}for the inputs involved. What differs isvim.lsp.util.apply_text_edits. Given byte for byte the same edit:{ newText = "", range = { start = { line = 1, character = 0 }, ["end"] = { line = 1, character = 0 } } }on a buffer holding
{"hello"}:{"hello", ""}{"hello"}0.12 looks correct there. A zero width range with empty
newTextis a no-op.The edit comes from
create_text_editinlua/conform/runner.lua:When the insert is at the end of the buffer that condition is false, so nothing is appended and
newTextends up empty. The comment says the newline is implicit there, which held only because the oldapply_text_editsadded the line anyway.So it is not just the test: any formatter whose output ends with an extra blank line has that line silently dropped on 0.12. Reproduced with a formatter that just prints
hello\n\nagainst a buffer containinghello.Fixing it means emitting a real edit for the append-at-EOF case, anchored at the end of the last line with a leading newline in
newText, rather than an empty range. Happy to send a patch if you want it done that way, but it touches the edit path everyone hits on save, so I would rather you pick the shape first.