Copilot autocomplete is ignored when there are trailing lines in a document, and no characters present on the line of the suggestion. The tab key inserts spaces instead

[Raees678]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

When pressing tab to autocomplete a suggestion given by copilot, the editor will accept the copilot suggestion if there are no trailing lines in the document. However, if a trailing line exists, the copilot suggestion is ignored, and tabs are inserted. This is unexpected since it should accept the copilot suggestion but does not.

This only happens when no text is entered and a copilot suggestion is available anyway such as when closing brackets, etc. If text etc. is entered and subsequently a copilot suggestion exists, pressing tab has the expected behavior of autocompleting the copilot suggestion, even if trailing lines are present.

The attached videos show Rust but I was able to replicate this in JS and TS too, so it seems to be language agnostic I think.

Environment

Zed: v0.97.5 (stable) OS: macOS 13.4.1 Memory: 64 GiB Architecture: aarch64

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

The first video shows the unexpected behavior. Spaces are inserted despite a copilot suggestion being present.

https://github.com/zed-industries/community/assets/10237081/17f27674-c9f4-49ea-b357-5b288c73497e

These two show the expected behavior. Whenever a copilot suggestion exists, pressing tab should insert that. This occurs when trailing lines do not exist, or at least 1 char is present on the line where copilot suggestions are being inserted.

https://github.com/zed-industries/community/assets/10237081/c7727663-3edd-4c4b-bc86-49934d6c02a5

https://github.com/zed-industries/community/assets/10237081/b13e2dd9-fb07-46fa-92cb-9e9c07ff208d

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

If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.

Tailing the logs while trying to get it to accept the autocomplete suggestion shows no new output. Still the last 1000 lines of logs are attached below. zed-log.txt

[maxbrunsfeld]

Thanks for the detailed report.

[acusti]

i ran into this behavior while trying to use tab to accept a copilot suggestion for a case statement in a .js file. here’s what is looked like for me (i’m just hitting the tab key then undo):

https://github.com/zed-industries/community/assets/517889/8681a899-caa5-4768-8033-36eb88e93d3c

note that the first time i got into this state, i actually had to type case (including the space) before i could tab-complete the suggestion, but i didn’t think to make a screen recording of that instance.

[titouandk]

Same here:

https://github.com/zed-industries/zed/assets/5413308/3b06bfa6-b6a7-4a8a-bf21-11ed441e176f

[mmtftr]

I've found the issue here https://github.com/zed-industries/zed/blob/f4a86e6feac496f4f5c1ca46e229f04a3896fd19/crates/editor/src/editor.rs#L4524-L4555

The code is first looking to see if the suggested indent should be applied, then it looks at a copilot suggestion.

Reversing the order fixes the issue but I'm not sure if that's the desired behavior. I can open a PR for this but I'd like some guidance from others.

[dxts]

There's another related issue to this, copilot completions are only shown when the content starts at or after the cursor. But if the completion would have started behind the cursor on the same line, nothing is displayed.

Most common example is when the cursor is on the last empty line of a function, there is no inline completion for the closing brace, unless you manually move the cursor back to the right indentation level. Other affected use cases are else if statements, case statements etc, where you need to move back an indentation level before continuing.

Here is a video comparing it with VSCode behaviour. (The second issue in the video was that the closing-brace inline completion was not accepted by pressing tab even after the cursor was moved back manually, but that seems to have been fixed in #9952)