Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add optional getSuggestionDetailsOnSelect to provider api #925
This adds an optional hook to the provider api:
This is useful in providers like the language server providers because getting additional details about the suggestion can be expensive.
It takes one of the suggestions previously received via
I'm on the fence about the name. Internally, we call this action "select", but that sounds like the user is choosing this suggestion. We call choosing the selection "confirming". It could be
Another thing I'm not sure about: should the left/right labels go away when the selection moves on?
@damieng we can still potentially do a hook like
@damieng I'm actually thinking that perhaps we don't call
Also, I have performance worries about the "visible event" you mentioned because of the repeated renderings. I think probably the provider should just look at the config setting to determine how many suggestions will be visible and go ahead and resolve those suggestions upfront on the
Does anyone have any opinions on the
Not sure I understand the first keystroke problem.
The problem with doing them all upfront on a single call is we can't return any then until the last visible one is resolved. I quite like the idea of showing the initial list as fast as possible then filling in the details.
I wouldn't worry about calling it multiple times - I'm caching the results and when you ask to resolve something I've already resolved I just return the same instance.
The new name for the method is probably more accurate, +1
@damieng the way this branch is working currently is that we call
The alternative would be to have the language server provider resolve the first item in the list right away as part of the
We can certainly try it - my only concern is that I can't issue a resolve request until the completion request has completed, so they will be sequential.…
On Sat, Nov 18, 2017 at 9:52 PM leroix ***@***.***> wrote: @damieng <https://github.com/damieng> the way this branch is working currently is that we call getSuggestions, render the suggestion list, call getSuggestionDetailsOnFocus (if available) for the first item in the list, and re-render the first item. We've done a lot in autocomplete-plus to try to minimize the scripting/rendering work that happens on every keystroke as much as we possibly can. The reason is that key strokes can come as close as 30ms apart, and if there's still scripting/rendering going on when the next keystroke occurs, it leads to a janky typing experience. The alternative would be to have the language server provider resolve the first item in the list right away as part of the getSuggestions call, but you're right. We wouldn't be able to show the list until /resolve completes. My intuition is that this will only take around a millisecond. Do you have some experience with how long the language servers usually take to respond to completion and resolve requests? There's also, of course, time spent parsing JSON. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#925 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHQp5XXx-Df9CSX8jO_JLxKvB9ELTD4ks5s38IigaJpZM4Qf0hU> .