Repository navigation
Support InsertReplaceEdit in CompletionItem #28
Description
Since LSP 3.16.0, CompletionItem supports either *TextEdit or *InsertReplaceEdit for the field TextEdit. The current implementation in Go supports *TextEdit only.
After a quick review, the following changes seem to be needed to cater for this additional type. Most likely language_gojay_test.go and language_test.go need to be modified too, but the needed code changes are less obvious to me. I'm more than happy to submit an initial PR too, let me know what you prefer.
language.go
diff --git a/language.go b/language.go
index 221d72a..f5be379 100644
--- a/language.go
+++ b/language.go
@@ -257,7 +257,7 @@ type CompletionItem struct {
// contained and starting at the same position.
//
// @since 3.16.0 additional type "InsertReplaceEdit".
- TextEdit *TextEdit `json:"textEdit,omitempty"` // *TextEdit | *InsertReplaceEdit
+ TextEdit interface{} `json:"textEdit,omitempty"`
}
// CompletionItemKind is the completion item kind values the client supports. When this
language_gojay.go
diff --git a/language_gojay.go b/language_gojay.go
index 2e9e38a..f6a992b 100644
--- a/language_gojay.go
+++ b/language_gojay.go
@@ -188,7 +188,7 @@ func (v *CompletionItem) MarshalJSONObject(enc *gojay.Encoder) {
enc.StringKeyOmitEmpty(keyLabel, v.Label)
enc.BoolKeyOmitEmpty(keyPreselect, v.Preselect)
enc.StringKeyOmitEmpty(keySortText, v.SortText)
- enc.ObjectKeyOmitEmpty(keyTextEdit, v.TextEdit)
+ enc.AddInterfaceKeyOmitEmpty(keyTextEdit, v.TextEdit)
}
// NKeys returns the number of keys to unmarshal.
@@ -233,10 +233,7 @@ func (v *CompletionItem) UnmarshalJSONObject(dec *gojay.Decoder, k string) error
case keySortText:
return dec.String(&v.SortText)
case keyTextEdit:
- if v.TextEdit == nil {
- v.TextEdit = &TextEdit{}
- }
- return dec.Object(v.TextEdit)
+ return dec.Interface(&v.TextEdit)
}
return nil
}
Activity
create-issue-branch commentedon Jul 25, 2021
Branch issue-28-Support_InsertReplaceEdit_in_CompletionItem created!
zchee commentedon Jul 25, 2021
@markdumay Thanks for the post issue.
Firstly, the
gojaybinding is faster than stdlibenconding/json, because I think you already know, uses a JIT stream parser.But unfortunately, "JIT" parser is not a good fit for the
interfacetype (not meansinterface{}field type).Which requires to define belows new type, and support it to gojay JIT methods:
I knew your said problem that's
protocolpackage doesn't fully support LSP specifications. But I faced the above problem , and didn't focused fixing it when that time. In that time, I'd focused to write all type of lsp 3.16 spec.I'll dig again gojay internal. Could you wait a moment?