[vim/vim] Make matchfuzzy less slow(make it unnoticeable) (#8359)

[smekkley]

matchfuzzy seems to block a little too long when the list is bit too big.
I would like a feature to workaround the issue.

Describe the solution you'd like

1. async support, something like matchfuzzy_async(str, list, callback, timeout)
   The underlying function would create a thread, monitor the status periodically until timeout, if success call the callback in the main thread, with the result and the list.

2. Partial response support. matchfuzzy_limit(str, list, max_match_num)
   fuzzymatch would stop searching for matches once max_match_num is found.

Describe alternatives you've considered
job_start and use other fuzzy finder process. it works but it feels bit of a waste if there is builtin function.

Additional context
I don't know anything about vim architecture or design policy. Please feel free to close the issue if it's not feasible or etc. I'm especially interested in solution 1. 2 is nice to have if 1 is supported to make the callback happen faster.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Bram Moolenaar]

> matchfuzzy seems to block a little too long when the list is bit too big.
> I would like a feature to workaround the issue.
>

> **Describe the solution you'd like**
> 1. async support, something like matchfuzzy_async(str, list, callback, timeout)

> The underlying function would create a thread, monitor the status
> periodically until timeout, if success call the callback in the main
> thread, with the result and the list.

Multi-threading is problematic, Vim does not use it.

> 2. Partial response support. matchfuzzy_limit(str, list, max_match_num)

> fuzzymatch would stop searching for matches once max_match_num is found.

Would this be much different from passing in a short list and then
repeat until you have sufficient matches? Sorting on score might not be
the best, but if you wet a maximum you might miss higher scored matches
anyway.

> **Describe alternatives you've considered**

> job_start and use other fuzzy finder process. it works but it feels
> bit of a waste if there is builtin function.
>

> **Additional context**

> I don't know anything about vim architecture or design policy. Please
> feel free to close the issue if it's not feasible or etc. I'm
> especially interested in solution 1. 2 is nice to have if 1 is
> supported to make the callback happen faster.

--
ARTHUR: I've said I'm sorry about the old woman, but from the behind you
looked ...
DENNIS: What I object to is that you automatically treat me like an inferior...
ARTHUR: Well ... I AM king.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[smekkley]

Ok. Even though I wish there'd be some asynchronous vim functions in addition to job_start, please feel free to close the issue. sounds like multiprocess is the way for heavy vim plugin by design. Thanks for explaining!

[Bram Moolenaar]

Using a job with a channel is the current solution to this. It's a bit of work to set it up, but has the advantage that the job can die or get stuck without making Vim unusable. Also, it allows for your custom solution without changing the Vim core.

[Bram Moolenaar]

Closed #8359.