arguments autocompletion eats up stuff randomly

[eulerdisk]

Summary

Autocompletion eats up text randomly completing arguments.
See the asciinema.

The cursor is at line 84 when writing the test function. Autocompleting the second suggested arguments something strange happens, about 60 lines of code above disappear. You can see the cursor now is at line 26.

It happened even autocompleting the first argument but it's hard to reproduce.

Maybe it's a RA problem. You can see the "overlapping edits" error.

Reproduction Steps

https://asciinema.org/a/4ZlV4d3AkvQ3gDC4qGLDbq3eD

Helix log

No response

Platform

WSL

Terminal Emulator

Windows Terminal

Helix Version

helix 22.12 (d63e570)

[pascalkuthe]

I have some ideas here. I think this might actually be a RA problem and I might even know what the problem in RA is but for that to work I would need a reproduction case. Is that example public anywhere or could you provide the file?

[eulerdisk]

The code is copy-pasted from the book "Zero to production in rust", which with I'm playing around these days.

https://github.com/eulerdisk/for_helix_debugging
You can find file/position from the asciinema.

I tried even with the original code from the book repo, but I wasn't unable to reproduce :-(

[pascalkuthe]

thanks! I can reproduce this, I think this might be a RA problem. The fact the helix complains about incorrect edits is a pretty strong indicator

[eulerdisk]

Either way, I think it would be better to do nothing than to do harm in these situations.

[pascalkuthe]

Ok looking at the logs here RA just sends us bogus edits. The reason for this (which I expected) is that you are inside a proc macro which is more difficult to RA to handle. Removing the tracing attribute remove the bug. I think tracing might be sending incorrect spans causing RA to map all positions back to the attribute argument instead of the function body.

The same issue also occurs with older versions of helix (I tested the 22.12.0 tag for example) however there helix refuses to apply the transaction. The reason for this is that we now use the insert edit now instead of the replace edit (which is even more broken).

Removing the tracing attribute fixes the completion.

One very interesting thing I found is that VScode will not even these completions while the tracing attribute is there but as soon as its removed they showup. Either VScode provides something to RA that makes it not send these completions in that case or (more likely) VScode detects that these completions are malformed and doesn't show them. We also get a protocol error here so maybe the right fix is to somehow ignore completions on protocol error.

Regardless that is really just about a better way to deal with a broken LSP. This is definitly a RA bug (altough it might be a known bug)

[pascalkuthe]

Either way, I think it would be better to do nothing than to do harm in these situations.

I mean I agree but it's not easy to figure out if/when an edit is incorrect. VSCode seems to do it somehow but it might be something rust specific, I am not sure yet

[eulerdisk]

I think maybe it's a duplicate of #5693.

[woojiq]

It is fixed in the nightly RA, though I can reproduce it on stable. I don't know when nightly ra becomes stable but It was probably fixed in rust-lang/rust-analyzer#11014 (merged a year ago)

Tested with rust-analyzer 1.73.0-nightly (864bdf7 2023-07-25)

[pascalkuthe]

stable RA is ancient and I would strongly advise against using it. Either use nightly ra or don't install it using rustup at all.

That said I tried to reproduce this a few weeks ago and was still able to (I use nightly RA)

[pascalkuthe]

Yeah I can still reproduce this