@brammool

Is this really useful? In some cases this list can be very long,
slowing down the operation.

I consider this point.
It is possible to avoid it by specifying only the entry you want to get in the argument {what}.

"Index is -1 if no item is selected (showing typed text only)"

Thanks. I'll reflect later.

@h-east What is an example of what argument. Do we use it like this? let info = complete_info({ 'mode': v:true })? I think it would be good to have an example of this in docs.

@brammool I think getting items is useful as this would allow plugin authors to enable fuzzy search on it though I have no plans to support this in asyncomplete anytime soon.

@prabirshrestha
Thank you for the suggestion.
I added an example in the document.

                Examples:
                        " Get all items
                        call complete_info()
                        " Get only 'mode'
                        call complete_info({'mode': ''})
                        " Get only 'mode' and 'pum_visible'
                        call complete_info({'mode': '', 'pum_visible': ''})

Codecov Report

Merging #4106 into master will decrease coverage by <.01%.
The diff coverage is 88.33%.

@@            Coverage Diff             @@
##           master    #4106      +/-   ##
==========================================
- Coverage   79.25%   79.25%   -0.01%     
==========================================
  Files         105      105              
  Lines      141171   141231      +60     
==========================================
+ Hits       111892   111933      +41     
- Misses      29279    29298      +19

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ba4238...0a14dc6. Read the comment docs.

@prabirshrestha, can you explain further how having the items field would allow a plugin to implement fuzzy search?

@h-east using empty string seems a bit weird because it is mostly falsy empty('') == v:true. I would except something like this instead where 1 or v:true returns the object and 0 or v:false ignores it.

let info = complete_info({ 'items': 1, mode: 0 }) " { items }
let info = complete_info({ 'items': v:true, mode: v:false }) " { items, mode }

@andymass
I haven't tried it but for v2 branch of asyncomplete.vim you could do something like this.

function! s:omni_completor(opt, ctx) abort
    let mode = complete_info({ 'mode': '' })['mode']
    if mode == 'omni'
        let items = complete_info({ 'items': '' })['items']
        let startcol = col('.')
        call asyncomplete#complete(a:opt['name'], a:ctx, startcol, items)
    endif
endfunction

call asyncomplete#register_source({
    \ 'name': 'omnifunc',
    \ 'whitelist': ['*'],
    \ 'completor': function('s:omni_completor'),
    \ })

function! s:myfuzzy_asyncomplete_preprocessor(ctx, matches) abort
    " implement sorting/ranking and fuzzy match on a:matches
    " this function is called before asyncomplete.vim shows the popup
    call asyncomplete#preprocess_complete(a:ctx, l:items)
endfunction

let g:asyncomplete_preprocessor = [function('s:myfuzzy_asyncomplete_preprocessor')]

You would also like to handle pum open autocmd and call asyncomplete#complete if mode is omni but that autocmd doesn't exist yet - #4083. In asyncomplete.vim you can call that as many time as you want anytime.

v2 also now supports preprocessor which runs right before it shows the menu so you can modify the items. https://github.com/prabirshrestha/asyncomplete.vim/blob/f1cc9e3c9e952c666652152c38089c89471f4e18/doc/asyncomplete.txt#L55-L87 This pre-processor runs in every keystroke so you can easily implement fuzzy find. Asyncomplete also caches the sources based on startcol you don't have to worry about checking complete mode all the time. preprocess api is designed to be future compatible which mean you can call asyncomplete#preprocess_complete multiple times as well as asynchronously. You could create a preprocessor that run's in python thread so it doesn't block the UI. This is also why I have been very interested in builtin ducktype ecmascript support with webworkers support. It opens a lot of possibilities like these very easily. Because this preprocessor can now run without changing the core asyncomplete vim plugin it will be interesting to see how others write their own and share. Fuzzy finding is just one piece of the better autocomplete, to make it really shine one needs to implement MRU and ranking for autocomplete.

I had thought of array of string but since I would call this function in every keystroke it would need to be fast.

Having said that arrays are still better interms if api.

Why use new pr? what is the different #4106 and #3866

@wsdjeg
I sent a patch that was almost completely rewritten on # 3866.
Despite the reviews I have repeatedly made, he kept subtle.
(and he has never said thanks-word)

I do not want to waste time with me and Vim developers any more.

@brammool

I don't think it is needed to use a dictionary argument. We can use a
list of strings, that is simpler:
[...]

I made it a dictionary because I referred to {what} of getqflist(), but the list is good for this API.

Updated asyncomplete v2 to use the new apis and it works great. prabirshrestha/asyncomplete.vim@623c744

Any chance we can get this PR merged to master soon?

@brammool (cc: @prabirshrestha )
I am busy for about a week, so I can not do this PR's work.
if possible, import as it is or improve.

--
Best regards,
Hirohito Higashi (h_east)

@prabirshrestha @brammool If you have opinion about this patch, pleaes let me known. I'll take over the work.

It is ready to be merged from my side.

@brammool Any update on this? Any concerns blocking the merge to master?