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

Don't replace next token on autocomplete #3365

Open
powellnorma opened this issue Apr 25, 2024 · 6 comments
Open

Don't replace next token on autocomplete #3365

powellnorma opened this issue Apr 25, 2024 · 6 comments
Milestone

Comments

@powellnorma
Copy link

powellnorma commented Apr 25, 2024

Is your feature request related to a problem? Please describe.

Let's say the line currently is:
someLongVariableName.Name()

When I now place the cursor before someLongVariableName, and type strings.HasP + [enter], the line becomes:
strings.HasPrefix().Name()

I think it would be better if it would become one of:
strings.HasPrefix(someLongVariableName.Name() (missing closing bracket)
strings.HasPrefix(someLongVariableName.Name()) (with closing bracket)
strings.HasPrefixsomeLongVariableName.Name() (cursor being in front of someLongVariableName)

Describe the solution you'd like

If this isn't a bug (it sort of feels like one, though), can we get a setting with which we can control this behavior?

Thank you!

@gopherbot gopherbot added this to the Untriaged milestone Apr 25, 2024
@findleyr
Copy link
Contributor

We agree that this is annoying, and doesn't happen in other LSP clients so may not be directly related to gopls.
Needs more investigation.

Even if we're not smart enough to include the variable as an argument, we should not be deleting existing text.

@findleyr findleyr modified the milestones: Untriaged, v0.43.0 Apr 25, 2024
@aaomidi
Copy link

aaomidi commented Apr 30, 2024

VSCode has this setting:

  "editor.suggest.insertMode": "insert"

However, it seems that each extension needs to opt into supporting it, and I assume vscode-go hasn't? Also, I don't believe I had this issue in the past, but my memory might be playing tricks on me here. There is a chance this is a regression?

I'd appreciate this being prioritized, or if not, some pointers to where in the codebase this may be happening. I can spend some time researching this and sending a PR.

@hyangah
Copy link
Contributor

hyangah commented May 9, 2024

@findleyr Is this working in other editors?
I thought about golang/go#61215
but maybe it is something else?

Repro:

package main

import (
	"fmt"
	"strings"
	"os"
)

func main() {
	var someLongVariableName S
	fmt.Println(someLongVariableName.Name()) // "someLongVariableName" LSP position (10:13-10:33)
}

type S string

var _ = strings.Compare

func (s S) Name() string {
	return string(s)
}
...

@hyangah
Copy link
Contributor

hyangah commented May 10, 2024

I think this needs golang/go#61215.

In this specific example, triggering completion after typing s after (

    fmt.Println(ssomeLongVariableName.Name())
                ^
                + trigger completion

gopls returns completion items, whose text edit ranges are always the whole ssomeLongVariableName token in this case, regardless whether the editor insert mode is insert or replace.

[Trace - 5: 11: 59 PM
] Sending request 'textDocument/completion - (453)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/hakim/xx/main.go"
    },
    "position": {
        "line": 10,
        "character": 14
    },
    "context": {
        "triggerKind": 1
    }
}



[Trace - 5: 11: 59 PM
] Received response 'textDocument/completion - (453)' in 11ms.
Result: {
    "isIncomplete": true,
    "items": [
         ...
        {
            "label": "strings",
            "kind": 9,
            "detail": "\"strings\"",
            "documentation": {
                "kind": "markdown",
                "value": ""
            },
            "sortText": "00001",
            "filterText": "strings",
            "insertTextFormat": 2,
            "textEdit": {
                "range": {
                    "start": {
                        "line": 10,
                        "character": 13 <---- begining of `ssomeLongVariableName`.
                    },
                    "end": {
                        "line": 10,
                        "character": 34   <------  end of `ssomeLongVariableName`.
                    }
                },
                "newText": "strings"
            },
 
            ...
        },

This old style TextEdit is translated to a VS Code CompletionItem with a single Range.
https://code.visualstudio.com/api/references/vscode-api#CompletionItem.range
I guess, if the range is not omitted, VS Code respects what the provided range.
Since gopls always gives the word boundary, VS Code ends up replacing the entire word boundary.

@gopherbot
Copy link
Collaborator

Change https://go.dev/cl/585275 mentions this issue: gopls/internal/server: support InsertReplaceEdit completion

@thedemons
Copy link

Any progress on this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants