Asynchronous, non-blocking matching

[d11wtq]

From kien#542:

Note: This is a PR from master..master and looks very unclean.

Hello,

I've been playing around with making the matching phase of ctrlp asyncrhonous, since that was the biggest bottleneck when working on big projects.

I've reached the phase where things are actually looking good and I would like more eyes on the changes, and comments on whether this would be a good candidate for merging.

There are basically two sets of changes:

1. The core of ctrlp is changed so that matching functions call a public #process function when they are done with the result, rather than returning it. This requires the current match plugin interface to be broken, but also allows plugins like cmatcher to execute their matching function in a separate/process thread, and then give the result to ctrlp for processing.
2. A public function #forcecursorhold is introduced to force a cursorhold autocommand. This is in the core since only that has the necessary information to produce a cursorhold event without actually changing anything. Of course, matcher functions can also use the remote expression interface of vim for truly asynchronous matching.
3. The match plugin interface now allows plugins to define whether they want ctrlp to always force an update, via the 'force_update' key. This is necessary when using the cursorhold event for asynchronous work.
4. Finally, a matcher written in python is introduced, and used when vim has python support and lazy updating is active. The python matcher does the matching and sorting in a separate thread, and uses the cursorhold event to check if the thread has finished its work. The matcher is a drop-in replacement to the viml matcher and supports everything, including regexp matching using the vim regexp syntax

[mattn]

It's hard to look this. haha.

[tacahiroy]

oh - man :0
need 1 year to look at this top to bottom

[d11wtq]

Yeah, @urandom, was the original PR like this, or has it gotten bloated from other commits over the past year?

[d11wtq]

I don't think this is likely to be merged. There's a lot going on in this PR, including the introduction of Python. It's not very clean IMHO.

Shall we close it?

[urandom]

@mattn
Why is it hard to look at? I specifically broke things down into smaller commits so that they are easy to understand. And for such a large feature, most commits are actually for the new files which support it. And those files should be easy to understand by anyone, since you don't need to look at the diff at all for them.

@d11wtq
Suit yourself. I don't even know what this repository is. The PR was made for kien's repo a long time ago. And it seems the intent here is to show PRs with the sole purpose of mocking them.

[d11wtq]

@urandom it's just a very large change set sent from master, so it's hard to identify if the change set is clean or not. However, since it introduces Python, it's probably not suitable for the ctrlp code base, which is intentionally written in Pure Vim.

See kien#591 as to why this repo exists. Rest assured, nobody is mocking anybody.

[mattn]

@urandom I can read python. But I can't say whether this patch breaks behavior or not immediately.