It's this related to #148 ?

Doing that would slow down completions in unacceptable way IMO.

LSP spec has concept of resolving extra completions info (documentation and stuff) but that is to be done by the client, on a per-completion basis and not all at once.

Also limiting completions sounds wrong. If I'm trying to complete some property and I'm not seeing it then I'll assume it doesn't exist. Unless you are thinking of using isIncomplete flag which would be fine and might speed up things on protocol level but on the tsserver level it probably won't help if it can't return partial results.

#148 looks similar, yep

Not sure how this needs to be implemented yet. Similar implementations have always been acceptably fast for me even when front loading all completion details. From there, we can probably implement some different completion strategies

• isIncomplete is the closest native solution. I think we might be able to work around tsserver's lack of partial results (grab un-detailed results and only return pages of those w/ detailed results? Maybe something else I've not thought of)
• Over, say, 500 completions we could only return the un-detailed completions instead of grabbing details for everything. This might look more like a bug than an intentional design decision though
• Worst case, the user decides that they're unhappy with the speed of completions and can start the server disabling the detailed completions

Ultimately, I want this project to have completion support on-par with other native solutions I'm used to working with (ALE and nvim-typescript on the VIM side). Considering we're both using the same tsserver behind the scenes, I definitely think that's possible without sacrificing performance unacceptably

Edit: Clarity

@rchl figured I'd share the WIP PR #167

Please let me know if that is super slow for whatever reason on your setup :)

Still fiddling around with some performance things, but I'm wondering at this point if it's a Neovim specific problem. Also I need to add a command flag as a kill switch

I've tested in one project, trying out to perform the same completion multiple times in both codebases.

The average time for the response to come with this new code was 1000ms.
With the master code, it's 50ms.

The number of returned completions was around 60 so it's not about the number of completions so much as the extra details that the server has to fetch, I guess.

From my perspective, that's an unacceptable performance regression. Feels very sluggish.

This(ex #167) was merged with:

7e73f59

@predragnikolic that was a mistake and was reverted

@DonnieWest any update on this? I've configured typescript-language-server with nvim-lspconfig, but when I use omnifunc for completion, I'm not able to see type / method signature. Do I need to pass some additional options when starting typescript lsp server?

@lowski tl;dr - we've worked on this in #167 but I've not yet figured out the performance issues we've run into. I've considered merging it under a flag but I still hesitate on doing that

That being said, I should probably test to see if the Neovim bug we ran into is still around

@DonnieWest thanks for quick response. FF via env variable for testing sound like reasonable option for testing it on bigger codebase pools.

Does your solution provide signatures for omnifunc? If so, I can test it on my side.

@lowski presumably, but I'm not sure how your client interprets our server specifically

@DonnieWest I'm using NeoVim 5.x with lsp-config with completion provided via omnifunc (v:lua.vim.lsp.omnifunc specifically). After adding nvim-compe, I'm able to see method / type signatures when I hover element on the list.

It seems that the current implementation of typescript-language-servers works fine but for some reason signatures are not included with default omnifunc config.

For editors that support auto-resolving completions when those are highlighted in the list this is not really an issue since the user will see the full information quick enough.

For editors that don't auto-resolve completions it's worse but I don't see anything we can do to help.

IMO this should be closed.

Agreed. This is effectively addressed by auto-resolving completions