[PATCH] D135508: [clangd] Heuristic to avoid desync if editors are confused about newline-at-eof
Sam McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Oct 10 03:17:37 PDT 2022
sammccall added a comment.
In D135508#3846231 <https://reviews.llvm.org/D135508#3846231>, @kadircet wrote:
> i also would rather not have the workaround solely for an editor (we usually try to address these on editor/plugin side).
Yeah, for sure. My main concern is that in practice it won't get fixed, but I'll open a new bug and see (the old one is closed because we thought it was fixed).
> i am also worried about the understanding of that inferred line afterwards (e.g. what if editor thinks that line doesn't have a trailing `\n` and send edits with that view of the world, or somehow attributes the `\n` to the next line instead)
The former can't really happen: the only edits that can touch this phantom newline either a) replace it, or b) replace text after it.
In the a) case it's gone so we'd agree with the editor, in the b) case... I can't imagine how a line-array-based editor could `x` on line 3 and then later claim line 2 and 3 are the same line as "I never added the newline".
> moreover, this won't fix the issue for existing clangd's (and until the next release).
This is very true, though it cuts both ways: if we fix nvim then nvim 0.5-0.8 remain broken. The release & update cadence there is pretty similar to clangd.
> so i'd rather get it fixed on the client side (and if we can't, i guess editors that can't have delta changes reliably just send full text as changes).
Turning off delta is an interesting idea, I'll mention that on the bug.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D135508/new/
https://reviews.llvm.org/D135508
More information about the cfe-commits
mailing list