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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
