llogick
llogick
> @nullptrdevs I could take care of rebasing this PR if you'd like. Yes, please do take over. PS Dropping `insertText` would require some work to support incomplete fields completions.
> FYI `insertText` gets converted into `textEdit` before sending the response. It was worth finding out, :+1:
Does your approval stand on this one, merge?
Having done this makes me realize having that logic is very dicey and https://github.com/zigtools/zls/blob/05ae41e3f4af684628c97a921b85e07d921f38e2/src/features/completions.zig#L1338 should just use `tok_loc.end` or https://github.com/zigtools/zls/blob/05ae41e3f4af684628c97a921b85e07d921f38e2/src/features/completions.zig#L1197 look_ahead = true here (haven't tested for side effects).
This is a low priority PR, the test changes are worth having, but in my opinion the fallback logic shouldn't exist (and obviously nothing depends on it currently).
Get the newest zls, those got ironed out in 54eaba2a7267166c832fd45f82a9aab9ba48642a
`same_name` and `same_last_token` aren't mutually exclusive though, should be `bool`s?
> > `same_name` and `same_last_token` aren't mutually exclusive though, should be `bool`s? > > So could you give an example where `same_name` but `same_last_token` doesn't. I were going off of...
Probably making use of `tags?: DiagnosticTag[];`, https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnostic
The strongest and only reason, to me, is being able to tell zls to use a specific zig version for a given project. Con: Can't publish it - paths have...