[feature request] - incremental/partial completion instead of longest/complete match

[aerosayan]

hello,

humbly requesting for a new completion method.

not sure if it already exists, since the help file doesn't mention it.

instead of matching the longest match, it would be better to incrementally complete the search.

consider the following labels...

foo_bar_zed_update
foo_dig_update
foo_dig_x_update
foo_update

i want to type foo_dig_x_update.

longest match will select foo_bar_zed_update.

i would like to avoid that.

it would be better to incrementally build up the label

as in ... f\<tab> -> foo_ -> foo_d\<tab> -> foodig -> foo_dig_x\<tab> -> foo_dig_x_update

this method is much more user friendly as you're building up your label incrementally, and this is how autocompletion in vs-code, visual studio and other advanced editors seem to work.

this is useful because many api calls are written in a similar nomenclature, as in openmp library ...

omp_get_num_threads()
omp_get_max_threads()
omp_get_thread_num()
omp_get_num_procs()
... etc

i don't know how to code vim plugins, so i don't know how the implementation will be like, but it might be possible to sort the possible matches then search in them to find the longest common partial substring.

thanks!

[ervandew]

Have you looked at setting completeopt (:help completeopt in vim) in your vimrc?

I have mine set as follows, where the longest option should be the part you want: set completeopt=menuone,longest,preview

supertab simply sends key codes to vim to start completion and navigate the results, but vim controls how the completion works.