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

Always return Completion.List with is_incomplete: true #398

Merged
merged 1 commit into from
Oct 11, 2023

Conversation

zachallaun
Copy link
Collaborator

@zachallaun zachallaun commented Oct 10, 2023

The :is_incomplete flag signals to the client that completions should be requested on every keypress. If it is not set, the client will generally issue a single completion request when the user starts typing a new "word", and then will filter client-side as subsequent letters are typed.

This causes problems for things like def foo do| -- VS Code, for instance, issues the request after the d of do is typed, and does not make another when the o is typed. This means you do not see the special-cased completion for a do/end block, but instead see a filtered list of completions for everything starting with d.

This commit also fixes two minor bugs: a small typo in a logged message, and correctly indenting the cursor after inserting the do/end block.

Before:

completions_incomplete_before

After:

completions_incomplete_after

@zachallaun zachallaun requested a review from scohen October 10, 2023 14:07
@zachallaun zachallaun force-pushed the za-always-incomplete-completions branch from 88d101f to bc5b082 Compare October 10, 2023 14:10
The `:is_incomplete` flag signals to the client that completions should
be requested on every keypress. If it is not set, the client will
generally issue a single completion request when the user starts typing
a new "word", and then will filter client-side as subsequent letters are
typed.

This causes problems for things like `def foo do|` -- VS Code, for
instance, issues the request after the `d` of `do` is typed, and does
not make another when the `o` is typed. This means you do not see the
special-cased completion for a `do/end` block, but instead see a
filtered list of completions for everything starting with `d`.
@zachallaun zachallaun force-pushed the za-always-incomplete-completions branch from bc5b082 to 95aa94b Compare October 10, 2023 14:56
Copy link
Collaborator

@scohen scohen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me locally. I didn't notice any difference in emacs.

@zachallaun zachallaun merged commit 9bd6958 into main Oct 11, 2023
6 checks passed
@zachallaun zachallaun deleted the za-always-incomplete-completions branch October 11, 2023 12:44
@zachallaun zachallaun mentioned this pull request Oct 11, 2023
2 tasks
zachallaun added a commit that referenced this pull request Oct 14, 2023
This commit reverts some of #398 in order to retain the previous, better
UX that users had in other editors, while still allowing completions to
work in VS Code.
zachallaun added a commit that referenced this pull request Oct 15, 2023
This commit reverts some of #398 in order to retain the previous, better
UX that users had in other editors, while still allowing completions to
work in VS Code.
zachallaun added a commit that referenced this pull request Oct 15, 2023
This commit reverts some of #398 in order to retain the previous, better
UX that users had in other editors, while still allowing completions to
work in VS Code.
zachallaun added a commit that referenced this pull request Oct 16, 2023
This commit reverts some of #398 in order to retain the previous, better
UX that users had in other editors, while still allowing completions to
work in VS Code.
zachallaun added a commit that referenced this pull request Oct 16, 2023
This commit reverts some of #398 in order to retain the previous, better
UX that users had in other editors, while still allowing completions to
work in VS Code.
zachallaun added a commit that referenced this pull request Oct 16, 2023
This commit improves completions for the general case and adds special handling when the client is VS Code that fixes numerous issues related to completions in that editor.

General improvements:

* Partially revert #398, which introduced a UX regression that caused slow/high latency completions.
* Don't insert additional, unnecessary newlines with multi-line snippets.
* Improved snippets for `defdelegate`, `defguard`, `defguardp`, `with`.
* Consistent capitalization and naming in completion labels.
* Fix a bug that caused a do/end block completion to be proposed when the cursor was after `@do`, which would occur whenever typing `@doc`.

VS Code:

VS Code has some problematic behavior when dealing with empty completion lists. When the client is VS Code, we now attempt to never send empty completion lists if it is possible that further typing will result in some completions. Instead, we send a larger list up front and allow the editor to filter.

See #400 for more context.

---------

Co-authored-by: Scott Ming <[email protected]>
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

Successfully merging this pull request may close these issues.

2 participants