UTF-8 characters break diagnostics' underline position
eshepelyuk opened this issue · comments
Because I've recently faced this when working with cspell.nvim
davidmh/cspell.nvim#32
I would like to revive this issue from null-ls
Possibly related?
none-ls.nvim/lua/null-ls/diagnostics.lua
Lines 45 to 90 in a3f8687
none-ls.nvim/lua/null-ls/utils/init.lua
Lines 61 to 72 in a3f8687
Possibly related?
none-ls.nvim/lua/null-ls/diagnostics.lua
Lines 45 to 90 in a3f8687
none-ls.nvim/lua/null-ls/utils/init.lua
Lines 61 to 72 in a3f8687
TBH not sure, i haven't dug that deep into a code.
But the issue still exists in none-ls
I've been looking into this issue, I think the problem comes from a conflict between the way Lua interprets strings with multi-byte characters and the way we pass the col
field through the patterns.
For example, the length for the string: · example typox
in every other language would be 15
, but Lua counts the bytes in the string, not the number of printable characters. This means that for the same string, lua returns 16
as the length of the string.
The report coming from CSpell also counts only printable characters, so for a file like this:
test.md
* example typox
· example typox
The report will be:
npx cspell --show-suggestions -c cspell.json lint --language-id markdown test.md
1/1 ./test.md 163.45ms X
./test.md:1:11 - Unknown word (typox) Suggestions: [typo, typos, type, typw, tyro]
./test.md:2:11 - Unknown word (typox) Suggestions: [typo, typos, type, typw, tyro]
Both lines have the same column as the start of the unknown word, because CSpell doesn't count bytes when reporting the position of the error.
So when we read the column from the report:
We just forward whatever we got from the CSpell report.
The end_col
ends up with the correct position because we calculate it with the custom from_quote
adapter, which finds the end column programmatically.
To counter that discrepancy, I plan on using the column reported by CSpell only as an index to start looking for the word reported as an error in the end_col
function, and mutating the entries table to define the col
property in the same function.
I have a proof of concept that seems to work as expected, I'll test a few scenarios before I push anything.
IMO, that feels a bit too hacky to keep as a long-term solution, we should look into validating the col
property in none-ls, maybe here:
none-ls.nvim/lua/null-ls/helpers/diagnostics.lua
Lines 60 to 82 in fa9be16
This issue was fixed in #36