LSP add basic autocomplete for nested definitions #4108
Conversation
This improves the autocomplete to handle nested definitions.
|
The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).
|
private/buf/buflsp/completion.go
Outdated
| ), | ||
| keywordToCompletionItem( | ||
| predeclaredTypeKeywords(), | ||
| protocol.CompletionItemKindTypeParameter, |
There was a problem hiding this comment.
nit: I think I'd also make this an ItemKindKeyword, since these predeclared type keywords are builtin to protobuf. (I think TypeParameter is maybe for generics?)
| protocol.CompletionItemKindTypeParameter, | |
| protocol.CompletionItemKindKeyword, |
There was a problem hiding this comment.
Switched to class to be consistent with gopls (is uses it for inbuilt types like int and defined ones). We could use struct for message types?
There was a problem hiding this comment.
class is fine with me. I think message types should match whatever gopls uses for structs, probably struct?
| } | ||
| if !yield(protocol.CompletionItem{ | ||
| Label: suggest, | ||
| Kind: kind, |
There was a problem hiding this comment.
nit: I think it would be nice to add a Detail or Documentation field to these CompletionItems if we have it, that would match info shown in hover? (I'm not sure which field is correct and/or better.) Feel free to file this as a follow-up.
Once we get into custom types as well, I think we'll want to populate the Deprecated field if we know it.
2 participants
This improves the autocomplete to handle nested definitions. Support for keywords within definition declarations is now supported. Basic support for predeclared types. Follow up will improve type support to autocomplete type sequences and modify existing type declarations.