Polishing the completion / suggestion

[benbenbang]

Hello team,

Thank you for the great work on Pyrefly! I'm enjoying using it with Zed, and the performance is great.

Feature request: Cleaner completion display

Currently, when I get completions, I'm seeing many overload signatures displayed, which makes them harder to scan quickly. I've noticed that Pyright presents completions in a more concise format. Is improving the completion display (perhaps showing a simplified signature with a way to expand for more details) already on your roadmap?

Question: TAB key for accepting completions

Is there a way to configure Pyrefly to accept completions with the TAB key? Most LSPs I use support this, and it's become part of my muscle memory. If this isn't currently configurable, would it be possible to add support for it?

Thanks again for building such a fast alternative 🙇‍♂️

[grievejia]

Would you mind providing some examples for the overload issue? I'd like to get a more accurate understanding of what exactly the feature ask is -- e.g. what is not displaying right, and what's the desirable outcome.

For TAB completion, I tried Pyrefly-in-Zed as well and TAB did give me completions. My impression was that it's usually a configuration on the editor side, not the language server side. But happy to be corrected if anyone knows which LSP message controls the behavior here.

[grievejia]

Thanks for the clarification! Yes I could confirm the issue here.

cc. @kinto0 -- this is what Pyright completion items look like in Zed:

And this is what Pyrefly completion items look like in Zed:

Some differences I noticed:

• Pyright doesn't put anything into the detail field in CompletionItems for the completion responses, while Pyrefly puts the entire overload signatures there. I think the overload signatures are far too long to be put into details. The Pyrefly completion items looks very crammed both in Zed UI and in VSCode UI.
  • I think we may want to change this, and move the overload signatures into the documentation field (perhaps above the docstrings?). I believe this is also what @benbenbang is trying to suggest.
  • We could still keep some text in details if we really want. But for the UI to look good I think that text should be really short.
  • Should we open an issue for this?
• Another interesting observation is that Pyright doesn't even include the documentation field in the initial completion responses. Instead, it relies on the completionItem/resolve request to lazily return the documentations.
  • This could be a nice small optimization that can shorten the initial completion JSON sizes.
  • There's also a related issue for this: Add Support For completionItem/resolve #1689

[benbenbang]

thanks for checking again 🙇‍♂️

[benbenbang]

Also @grievejia , I am not sure if I am asking too much 😅
But none of the LSP make this work:

Is it possible to sort the stdlib to be the first one?
For stdlib import, it shouldn't come from 3rd libs, right?

[benbenbang]

And another example:

I cannot see any signatures

[kinto0]

thanks for the reports! I don't use zed and it's unfortunate the formatting is like that. filed #1729.

Is it possible to sort the stdlib to be the first one?

very similar to #1685. I'll comment there with this new requirement

I cannot see any signatures

I had started working on this but unfortunately never finished. filed #1728