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

Autocomplete oddity for functions #302

Closed
bcardarella opened this issue Jun 19, 2020 · 12 comments
Closed

Autocomplete oddity for functions #302

bcardarella opened this issue Jun 19, 2020 · 12 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@bcardarella
Copy link

bcardarella commented Jun 19, 2020

Environment

  • Elixir & Erlang versions (elixir --version): 1.10
  • Operating system: OSX 10.15.4
  • Editor or IDE name (e.g. Emacs/VSCode): VSCode
  • LSP Client name: ElixirLS

Example of issue:

Jun-19-2020-02-35-35

As you can see the autocomplete for functions doesn't seem to be working correctly. I am unsure if this is related to #193 but I think it should be clear that do would be the preferred completion in this case.

@axelson
Copy link
Member

axelson commented Jun 21, 2020

@bcardarella there's two things related here. One is that we removed the override of "editor.acceptSuggestionOnEnter": "on": elixir-lsp/vscode-elixir-ls#52 so you could manually change that back. Also in #259 (not yet released on VSCode" this behavior is improved and since the server is always returning a completion. So this behavior will be better on the next release (which should be fairly soon)

@lukaszsamson
Copy link
Collaborator

lukaszsamson commented Sep 30, 2020

It still doesn't work right on current master

@axelson
Copy link
Member

axelson commented Sep 30, 2020

Hmm, I'll have to double-check

@lukaszsamson lukaszsamson added bug Something isn't working good first issue Good for newcomers labels Nov 28, 2020
@Hanspagh
Copy link
Contributor

This is fixed in the latest version for me.
def foo do returns no completions for me, which I assume is a reasonable behavoir

@lukaszsamson
Copy link
Collaborator

I can confirm it's fixed now though I'm not sure by which commit.

@bcardarella
Copy link
Author

bcardarella commented Feb 1, 2022

@axelson I reported in Slack but figured it is better here. This doesn't appear to be fixed. I'm on version 0.9.0 and seeing the same behavior from 18 months ago:
Feb-01-2022 18-48-49

@bcardarella
Copy link
Author

Can we just get exact matches to sort first? It seems reasonable if there is an exact match that is what the suggestion should be.

@axelson
Copy link
Member

axelson commented Feb 16, 2022

I haven't been able to investigate this since it re-appeared but I have a hunch that something changed on the VSCode sorting side of things. I'm fairly sure that ElixirLS is returning do earlier than defmodule.

@lukaszsamson
Copy link
Collaborator

lukaszsamson commented Feb 16, 2022

I haven't been able to investigate this since it re-appeared but I have a hunch that something changed on the VSCode sorting side of things. I'm fairly sure that ElixirLS is returning do earlier than defmodule.

I checked and we assign priority 0 to do in

defp maybe_add_do(completion_items, context) do

Later we sort by priority in

Finally we assign sortText basing on the sort order in
defp item_to_json(item, idx, options) do

For reference LSP client should sort on this property

	/**
	 * A string that should be used when comparing this item
	 * with other items. When `falsy` the label is used
	 * as the sort text for this item.
	 */
	sortText?: string;

There is alse filterText

	/**
	 * A string that should be used when filtering a set of
	 * completion items. When `falsy` the label is used as the
	 * filter text for this item.
	 */
	filterText?: string;

but we don't set it in that case so it defaults to label do

Maybe we should also use preselect on exact matches?

	/**
	 * Select this item when showing.
	 *
	 * *Note* that only one completion item can be selected and that the
	 * tool / client decides which item that is. The rule is that the *first*
	 * item of those that match best is selected.
	 */
	preselect?: boolean;

@sreecodeslayer
Copy link

This issue seems to be happening on SublimeText as well through this plugin.
Weird thing is, the second time I try the same line, "do" appears at the top of sort list, if not "defoverridable"

Screen.Recording.2023-02-24.at.1.29.47.PM.mov

@mhanberg
Copy link
Contributor

mhanberg commented Mar 3, 2023

image

Neovim

@lukaszsamson
Copy link
Collaborator

lukaszsamson commented May 18, 2023

If anybody is still experiencing this issue, here's more context (mostly vscode specific) #883 (comment).
The vscode solution is not having editor.snippetSuggestions set to top. inline or bottom work best #883 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

6 participants