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

Selecting an autocomplete item should not lose placeholder tabs #10185

Closed
1 task done
marwan-at-work opened this issue Apr 4, 2024 · 3 comments · Fixed by #11740
Closed
1 task done

Selecting an autocomplete item should not lose placeholder tabs #10185

marwan-at-work opened this issue Apr 4, 2024 · 3 comments · Fixed by #11740
Labels
autocompletions Feedback for code completions in the editor defect [core label] editor Feedback for code editing, formatting, editor iterations, etc

Comments

@marwan-at-work
Copy link

Check for existing issues

  • Completed

Describe the bug / provide steps to reproduce it

It's common to call a function and tab through its parameters because each param has its own tab-placeholder.

However, if we end up choosing an autocomplete item from the list within param1, we lose the ability to tab into param2.

See the below screen recording for demonstration.

Environment

Zed: v0.129.2 (Zed)
OS: macOS 14.3.0
Memory: 96 GiB
Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

Screen.Recording.2024-04-04.at.5.24.52.PM.mov

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

No response

@marwan-at-work marwan-at-work added admin read Pending admin review defect [core label] triage Maintainer needs to classify the issue labels Apr 4, 2024
@Moshyfawn Moshyfawn added editor Feedback for code editing, formatting, editor iterations, etc autocompletions Feedback for code completions in the editor and removed triage Maintainer needs to classify the issue labels Apr 4, 2024
@JosephTLyons JosephTLyons removed the admin read Pending admin review label Apr 5, 2024
@mrnugget
Copy link
Member

Here's more to reproduce:

  1. Create the following main.go file:
package main

import "fmt"

type Animal struct {
	Name string
}

func myFunctionWithArguments(a *Animal, numA, numB int) {
	fmt.Printf("animal: %+v, foo: %d", a.Name, numA+numB)
}

func main() {
	horse := &Animal{Name: "Horse"}

	//
}
  1. Create a new line to call myFunctionWithArguments:
    screenshot-2024-05-13-10 06 02@2x
  2. Hit tab to accept suggestion
    screenshot-2024-05-13-10 06 21@2x
  3. Type hor to get horse as suggestion:
    screenshot-2024-05-13-10 06 36@2x
  4. Accept suggestion with tab
  5. Try to hit tab to go to next parameter — does not work

in Vim mode, you now have to hit Esc and then go back in insert mode again and then hit tab.

@mrnugget
Copy link
Member

It's definitely a Go thing. It works in Rust

screenshot-2024-05-13-10.18.18.mp4

@mrnugget
Copy link
Member

Okay, more information:

  1. gopls sends even single-word-no-tab-stops completions as snippets. insertTextFormat = 2: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#insertTextFormat
  2. We then parse the snippet, which is just a single word, and fall to the default case of adding the end-of-the-word as the tab stop:
    let end_tabstop = [len..len].into_iter().collect();
    if !tabstops.last().map_or(false, |t| *t == end_tabstop) {
    tabstops.push(end_tabstop);
    }
  3. In combination that results in Zed accepting snippet for function-call, pushing it on stack, then accepting "snippet" for first parameter and pushing it on stack, when then tab is hit, the snippet on top of the stack is not the function call, but the identifier, and since we're already at the end of it, nothing happens.
  4. In Vim mode, when hitting Esc it basically triggers a "dismiss menus & completions" logic, which pops the current snippet off the stack. So when you then go back in insert mode, only the correct snippet is still left.

mrnugget added a commit that referenced this issue May 13, 2024
This fixes #10185 by not keeping snippet state around when already at
the end of the snippet and the tabstop is empty (i.e. it's not a
selection) and we're already on it.

The reason for the fix is outlined in the comments of #10185 but to
repeat:

1. `gopls` sends completions with type "snippet" even when suggesting
   single word completions that don't contain tabstops
2. We use a default behavior and add an "end tabstop" by default so that
   the cursor jumps to the end of the snippet when accepting it.
3. We'd then push the state of the snippet on the stack which is where
   it would stay, with the cursor already at the end and the user unable
   to get rid of the tabstop state.

This fixes the issue by not pushing snippet state when the tabstop we
accepted is the "end tabstop".
mrnugget added a commit that referenced this issue May 13, 2024
This fixes #10185 by not keeping snippet state around when already at
the end of the snippet and the tabstop is empty (i.e. it's not a
selection) and we're already on it.

The reason for the fix is outlined in the comments of #10185 but to
repeat:

1. `gopls` sends completions with type "snippet" even when suggesting
single word completions that don't contain tabstops
2. We use a default behavior and add an "end tabstop" by default so that
the cursor jumps to the end of the snippet when accepting it.
3. We'd then push the state of the snippet on the stack which is where
it would stay, with the cursor already at the end and the user unable to
get rid of the tabstop state.

This fixes the issue by not pushing snippet state when the tabstop we
accepted is the "end tabstop".

Release Notes:

- Fixed completions inside snippets breaking the jump-to-next-tabstop
behaviour when using Go/`gopls`
([#10185](#10185)).

Demo:



https://github.com/zed-industries/zed/assets/1185253/35384e5e-45c6-46ab-870d-b48e56d8786b
osiewicz pushed a commit to RemcoSmitsDev/zed that referenced this issue May 18, 2024
…s#11740)

This fixes zed-industries#10185 by not keeping snippet state around when already at
the end of the snippet and the tabstop is empty (i.e. it's not a
selection) and we're already on it.

The reason for the fix is outlined in the comments of zed-industries#10185 but to
repeat:

1. `gopls` sends completions with type "snippet" even when suggesting
single word completions that don't contain tabstops
2. We use a default behavior and add an "end tabstop" by default so that
the cursor jumps to the end of the snippet when accepting it.
3. We'd then push the state of the snippet on the stack which is where
it would stay, with the cursor already at the end and the user unable to
get rid of the tabstop state.

This fixes the issue by not pushing snippet state when the tabstop we
accepted is the "end tabstop".

Release Notes:

- Fixed completions inside snippets breaking the jump-to-next-tabstop
behaviour when using Go/`gopls`
([zed-industries#10185](zed-industries#10185)).

Demo:



https://github.com/zed-industries/zed/assets/1185253/35384e5e-45c6-46ab-870d-b48e56d8786b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autocompletions Feedback for code completions in the editor defect [core label] editor Feedback for code editing, formatting, editor iterations, etc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants