fix: use edit range start for compensation instead of old cursor

[soifou]

Using the edit's start as the reference keeps the range correct even if completions are refreshed or the cursor moves.

In substance,

The old logic assumes the difference between old and new cursor columns always reflects how much the edit range should move. But if the cursor moves, or if completions are refreshed (trigger char), the "old" cursor column can be completely out of sync with the actual edit range. This can result in negative values (because of the compute of new - old), causing the edit to go backwards or delete the wrong text (end char < start char).

The new logic always computes the offset from the start of the edit range, which I think is stable and always matches the text to be replaced. It only adjusts if the cursor has moved past the original end, expanding the edit to include new user input. It never produces a range where the end is before the start.

For history I was having this case for some time but did not had the time to dig that much:

---@diagnostic disable-next-line

Typing disable-next-line would put the cursor at the end of the ghost text. With this change the issue disappear as well.

Closes #1736
Closes #1978

[saghen]

Thanks!

[saghen]

Reverted this as the existing behavior seems like it may be correct. I found the root cause in blink-cmp-git: Kaiser-Yang/blink-cmp-git#60 (comment)

[soifou]

Ok, thanks for the heads up. You might want to close #1989 as well.

There's still an issue with the ghost text, though, but that's less blocking.

[ArttuLai]

Just to make sure, this specific issue is still happening to me in v1.6.0, while it was fixed in v1.5.0 and .1, afaik after this PR was reverted. I haven't found many situations to trigger it, but when my cursor is at | like here:

---@diagnostic dis|

and I trigger completion for disable, it completes into:

---@diagnostic disable|s

Completing ---@diagnostic completes normally, but basically anything after it in the same line leaves the last character of my typed text after the completion. E.g. if I continue:

---@diagnostic disable: un|

and trigger completion for unused-function, I’ll get:

---@diagnostic disable: unused-function|n

[soifou]

Just to make sure, this specific issue is still happening to me in v1.6.0

Yes, this is still happening, but it's an issue with the lua_ls language server reporting incorrect ranges, so it needs to be fixed upstream. If you switch to, for example, emmylua_ls (https://github.com/EmmyLuaLs/emmylua-analyzer-rust), it reports the correct ranges.