kien/ctrlp.vim — Issue #110: Prefer matching consecutive text
Author: eproxus
Created: 2012-01-23 11:13:20+00:00
State: open

When searching large code bases for a file, the matches often seem to be picked in a non-intuitive order.

For example, when searching the [Erlang/OTP](https://github.com/erlang/otp) code base with the string `cover.erl` which happen to match several full file name endings, the match list becomes:

> lib/cosEvent/src/CosEventChannelAdmin_EventChannel.erl
> lib/common_test/test/ct_test_server_if_1_SUITE.erl
> lib/common_test/test/ct_event_handler_SUITE.erl
> lib/cosEvent/src/CosEventChannelAdmin_ProxyPullConsumer_impl.erl
> lib/cosEvent/src/CosEventChannelAdmin_ProxyPullConsumer.erl
> lib/cosEvent/src/CosEventChannelAdmin_AlreadyConnected.erl
> lib/cosEvent/src/CosEventChannelAdmin_ConsumerAdmin.erl
> lib/compiler/src/v3_kernel_pp.erl
> lib/compiler/src/v3_kernel.erl
> lib/common_test/src/ct_cover.erl

However, the file that is the most fitting match is `lib/tools/src/cover.erl` doesn't even appear. That match only appears when typing `tools/cover.erl` as search pattern. This means that the user has to know that the `cover.erl` file is in the `tools` folder.

It would be more intuitive if the matching logic sorted by biggest matching pattern first. This way the results would be similar to a regexp search for `cover.erl` and much more usable:

> release/tests/dialyzer_test/r9c_SUITE_data/src/mnesia/mnesia_recover.erl
> lib/dialyzer/test/r9c_SUITE_data/src/mnesia/mnesia_recover.erl
> lib/mnesia/src/mnesia_recover.erl
> lib/common_test/src/ct_cover.erl
> lib/tools/src/cover.erl
> release/x86_64-unknown-linux-gnu/lib/mnesia-4.6/src/mnesia_recover.erl
> release/x86_64-unknown-linux-gnu/lib/common_test-1.6/src/ct_cover.erl
> release/x86_64-unknown-linux-gnu/lib/tools-2.6.6.6/src/cover.erl

Then why not use regexp search directly? Well, consider the two following matches:

> lib/cosEvent/src/CosEventChannelAdmin_ProxyPullConsumer_impl.erl
> lib/tools/src/cover.erl

Given the search for `cover.erl` the second match should be more prominent because it is most probably what the user wants. If one were to search for `CosEventChannelAdmin_ProxyPullConsumer_impl.erl` the search pattern would probably be one of the following:

* `CosEvent`
* `CECA` (for CosEventChannelAdmin)
* `ProxyPull`
* or `cosEvent/Admin` (for example)

None of these searches would even remotely be `cover` (which are just letters happening to be in the path). Therefore, sorting in a more intuitive way would not get in the way of finding the other matches (since they are not relevant anyway and would be found using other searches).