Repository navigation
Configurable timeout for 'complete' sources #17908
Description
Activity
The
autocompletetimeout can be made configurable; however, only a narrow range of values is practical before the popup window starts to feel sluggish—especially when multiple large buffers are open.As for
ctrl-N, I'm not sure why anyone would prefer it whenautocompletealready exists. That said, if the project leaders believe adding a timeout is worthwhile, I'm open to implementing it. However, it should remain a separate mechanism.As for
ctrl-N, I'm not sure why anyone would prefer it whenautocompletealready exists.Some (surprisingly large group of) people don't like the idea of autocompletion per se. So having on-demand completion which can be used with large buffers is an improvement.
It is also useful when implementing own autocompletion logic, which is my original motivation. I've been relying on
<C-n>as a fallback for years now and it works great. With one exception: it is blocking and can sometimes cause visible lag when typing. Being able to limit its blocking time while still returning relevant candidates is a great improvement here.However, it should remain a separate mechanism.
Do you mean configuring timeout for 'autocomplete' and for manual
<C-n>should be separate? If yes, could you please explain why? My thought was that they essentially set a time limit for the same completion sources, so might as well be the single option/flag. It also feels likely that user of 'autocomplete' will likely not use manual<C-n>and vice versa, so the situation of "I want one timeout for 'autocomplete' but the other for manual<C-n>" will not be that common.That said, if the project leaders believe adding a timeout is worthwhile, I'm open to implementing it.
@chrisbra, do you think configurable timeout for 'complete' sources is worthwhile?
Reacted by ddad431Do you mean configuring timeout for 'autocomplete' and for manual
<C-n>should be separate? If yes, could you please explain why?When the two timeouts are combined,
Ctrl_Nis no longer backwards compatible, as it inherits the abort-on-timeout behavior fromautocomplete. Users who are accustomed toCtrl_Ndoing exhaustive search may find that annoying—though they could always set the timeout to a large value. I will let chrisbra decide.I would think that the timeout option would make sense for users who do not want to use 'autocomplete' setting. But it is true, that this is backwards incompatible, perhaps we could use
timeout:0as a default, which means do not timeout? So that this would not break existing users experience?But it is true, that this is backwards incompatible, perhaps we could use
timeout:0as a default, which means do not timeout? So that this would not break existing users experience?That was my assumption as well: no timeout by default which is achieved either by missing
timeoutflag or setting it to 0. Sorry to not have said that explicitly.- added 2 commits that reference this issue
on Aug 11, 2025 - added a commit that references this issue
on Aug 23, 2025 - added a commit that references this issue
on Sep 7, 2025 - added a commit that references this issue
on Sep 27, 2025
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
Manual Insert mode completion (like after
<C-n>) is blocking and can take non-negligible amount of time to finish (like when there is a big buffer open).Recently #17812 introduced a concept of "timing out" a 'complete' source while returning candidates found within allocated time slot. If applied to manual completion, this seems to improve the blocking behavior.
The problem is that timeout is not configurable (which seems to be by initial design) and only applied when 'autocomplete' is enabled.
Describe the solution you'd like
A way to configure "timeout for 'complete' source" that will apply to both 'autocomplete' (probably as initial timeout before decay) and manual
<C-n>invocation (probably without decaying and applied to each source separately).Being able to configure this will improve both manual and auto completion experience.
One of the way to do it might be to allow a new
completeoptflag that configures timeout. Maybe something liketimeout:ms, so thatset completeopt+=timeout:500sets timeout to 500 milliseconds.The other way is a separate option, like 'completetimeout'.
Describe alternatives you've considered
Asking for manual completion to be non-blocking, but this seems to be too complicated. There seems to already be an infrastructure for "timeout" feature which is a reasonable solution.
Additional context
There is a note in #17812 that "Timeout values are intentionally not configurable". I do understand the "just work" approach, but the problem is that slow completion candidate computation might be a result of slow machine or generally slow LSP server. And although there might be small amount of candidates available within 80 ms window, it might be inconvenient to not have more candidates at the cost of small time increase (if user wants it).
Allowing users to adjust timeout seems like a not overly complicated way to solve this. So it can "just work" with enabled 'autocomplete', but still allow users to adjust for both auto and manual completion.
cc @girishji as you are the most qualified person to discuss and potentially add this.