Emacs

311 readers

1 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Windows
Mac OS X
GNU/Linux and BSD (Just get it from your distribution's package manager)

Rules

Posts should be emacs related
Be kind please
Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

Put the Caps Lock key to better use!

founded 1 year ago

MODERATORS

rglullis

raphael

Does eglot support autocomplete candidates with the same name? (alien.top)

submitted 11 months ago by darkawower@alien.top to c/emacs

10 comments fedilink hide all child comments

Hi guys, sometimes I try something new to compare with already used packages, this weekend I wanted to try Eglot, however, I ran into a number of problems. One of them is autocomplete.

For example, when I write in vue, I want to autocomplete a watch function. This function is available in the following packages

import { watch } from 'vue';
import { watch } from 'fs';
import { watch } from 'fs/promises'
... etc

But when I use autocomplete in eglot I only see the first candidate - importing from the fs package. Is there any possibility or workaround to display all possible candidates?

Example of autocomplete with eglot

https://preview.redd.it/tlgtg5imw43c1.jpg?width=2930&format=pjpg&auto=webp&s=7f0cd2ff1b6733ec26021b77b6e5e392f26921df

Example of autocomplete with lsp-mode

https://preview.redd.it/rcntp2vow43c1.jpg?width=1224&format=pjpg&auto=webp&s=a246d790c47b4d48a3fba5e5f1cb361841eccc02

I also know that lsp-mode in conjunction with corfu has a similar problem, but it is impossible to solve it there as the authors of both packages think that the problem is not on their side 😅 Is the situation with eglot the same?

you are viewing a single comment's thread
view the rest of the comments

[–] hvis@alien.top 1 points 11 months ago (7 children)

As long as the completions have the same annotation (the text in green) and same kind (the icon on the left), they are deduplicated.

Looks like perhaps lsp-mode generates annotations that are more useful for your scenario than the ones that eglot does. If that is the case (and not, maybe, that you have configured lsp-mode/eglot to use different language servers), I suggest filing an issue. This shouldn't take too much time to change.

[–] minad-emacs@alien.top 1 points 11 months ago (6 children)

/u/hvis Would you consider changing this, since this way of deduplication in the frontend is quite inefficient? Given that the default completion UI demands that candidates are unique with respect to equal and even deletes equal duplicates, the backend should better produce unique candidates.

Deduplicating in the backend is not difficult, all that is needed is adding a suffix like (1), (2), (3), ... In fact, this is what I am doing in my Consult package, which also is a backend and provides completion tables. For example for the consult-line command I was facing the same issue, that candidates must be unique with respect to equal and not to eq.

cc /u/JDRiverRun

[–] hvis@alien.top 1 points 11 months ago

Would you consider changing this, since this way of deduplication in the frontend is quite inefficient?

I simply consider it part of the requirements (see the other message). And there has been some effort made to ensure that the annotation/kind functions are only called when equal strings are encountered.

Indeed, when the list is long deduplication does show up on the graph, but the impact also depends on the shape of the data, and there probably are some untapped code optimizations still.

Deduplicating in the backend is not difficult, all that is needed is adding a suffix like (1), (2), (3), ...

I'm not sure this is very easy (e.g. for LSP clients), and in general it would require a scan across all completions of comparable complexity. Also, showing method overloads with suffixes like 1/2/3 would look rather odd, I think.

load more comments (5 replies)