Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support InsertReplaceEdit in CompletionItem #28

Open
markdumay opened this issue Jul 16, 2021 · 2 comments
Open

Support InsertReplaceEdit in CompletionItem #28

markdumay opened this issue Jul 16, 2021 · 2 comments
Assignees
Labels
area/protocol help wanted Extra attention is needed kind/specification Language Server Protocol specification

Comments

@markdumay
Copy link
Contributor

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
 }
@zchee zchee self-assigned this Jul 25, 2021
@create-issue-branch
Copy link

@zchee zchee added area/protocol help wanted Extra attention is needed kind/specification Language Server Protocol specification labels Jul 25, 2021
@zchee
Copy link
Member

zchee commented Jul 25, 2021

@markdumay Thanks for the post issue.

Firstly, the gojay binding is faster than stdlib enconding/json, because I think you already know, uses a JIT stream parser.
But unfortunately, "JIT" parser is not a good fit for the interface type (not means interface{} field type).

Which requires to define belows new type, and support it to gojay JIT methods:

type textEditInterface interface {
	isTextEdit()
}

type TextEdit struct {
	someFields...
}

func (TextEdit) isTextEdit() {}

type InsertReplaceEdit {
	someFields...
}

func (InsertReplaceEdit) isTextEdit() {}

I knew your said problem that's protocol package 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/protocol help wanted Extra attention is needed kind/specification Language Server Protocol specification
Development

No branches or pull requests

2 participants