[vim/vim] Add complete_info() function (#4106)
h_east
Once the specification is decided, refactor, update the document and add more tests.
complete_info([{what}])
Returns a Dictionary with information about insert mode
completion. see |ins-completion|.
The items are:
mode current completion mode name string.
See |completion_info_mode| for the values.
pum_visible |TRUE| if popup menu is visible.
See |pumvisible()|.
items List of completion matches. Each item is a
dictionary containing the entries "word",
"abbr", "menu", "kind", "info" and "user_data".
See |complete-items|.
selected Selected item index. First index is zero.
Set -1 if not selected.
inserted Inserted string. [NOT IMPLEMENT YET]
*complete_info_mode*
mode values are:
"" Not in completion mode
"keyword" Keyword completion |i_CTRL-X_CTRL-N|
"ctrl_x" Just press |i_CTRL-X|
"whole_line" Whole lines |i_CTRL-X_CTRL-L|
"files" File names |i_CTRL-X_CTRL-F|
"tags" Tags |i_CTRL-X_CTRL-]|
"path_defines" Definition completion |i_CTRL-X_CTRL-D|
"path_patterns" Include completion |i_CTRL-X_CTRL-I|
"dictionary" Dictionary |i_CTRL-X_CTRL-K|
"thesaurus" Thesaurus |i_CTRL-X_CTRL-T|
"cmdline" Vim Command line completion |i_CTRL-X_CTRL-V|
"function" User defined completion |i_CTRL-X_CTRL-U|
"omni" Omni completion |i_CTRL-X_CTRL-O|
"spell" Spelling suggestions |i_CTRL-X_s|
"eval" |complete()| completion
"unknown" Other internal modes
If the optional {what} dictionary argument is supplied, then
only the items listed in {what} are returned.
Unsupported keys in {what} are ignored.
Related Issue/Thread
#3866
https://groups.google.com/d/msg/vim_dev/6utE1ObSYY8/fOaLtsBUGwAJ
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/4106
Commit Summary
- Add complete_info()
File Changes
- M runtime/doc/eval.txt (41)
- M runtime/doc/insert.txt (1)
- M runtime/doc/usr_41.txt (1)
- M src/edit.c (99)
- M src/evalfunc.c (19)
- M src/proto/edit.pro (1)
- M src/testdir/test_popup.vim (43)
Patch Links:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Bram Moolenaar
> Once the specification is decided, refactor, update the document and add more tests.
>
> ```
> complete_info([{what}])
> Returns a Dictionary with information about insert mode
> completion. see |ins-completion|.
> The items are:
> mode current completion mode name string.
> See |completion_info_mode| for the values.
> pum_visible |TRUE| if popup menu is visible.
> See |pumvisible()|.
> items List of completion matches. Each item is a
> dictionary containing the entries "word",
> "abbr", "menu", "kind", "info" and "user_data".
> See |complete-items|.
slowing down the operation.
> selected Selected item index. First index is zero.
> Set -1 if not selected.
[...]
--
hundred-and-one symptoms of being an internet addict:
49. You never have to deal with busy signals when calling your ISP...because
you never log off.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
h_east
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.
Prabir Shrestha
@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.
h_east
@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
Codecov Report
Merging #4106 into master will increase coverage by
<.01%.
The diff coverage is87.75%.
@@ Coverage Diff @@ ## master #4106 +/- ## ========================================== + Coverage 79.24% 79.25% +<.01% ========================================== Files 105 105 Lines 141163 141222 +59 ========================================== + Hits 111860 111919 +59 Misses 29303 29303
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/evalfunc.c | 88.65% <62.5%> (-0.04%) |
⬇️ |
| src/edit.c | 86.23% <92.68%> (+0.1%) |
⬆️ |
| src/ex_cmds2.c | 84.89% <0%> (-0.1%) |
⬇️ |
| src/screen.c | 80.34% <0%> (-0.03%) |
⬇️ |
| src/quickfix.c | 93.44% <0%> (-0.01%) |
⬇️ |
| src/version.c | 86.28% <0%> (ø) |
⬆️ |
| src/ex_docmd.c | 80.6% <0%> (+0.01%) |
⬆️ |
| src/terminal.c | 79.08% <0%> (+0.04%) |
⬆️ |
| src/getchar.c | 75.41% <0%> (+0.04%) |
⬆️ |
| ... and 3 more |
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 55d81cd...ce0304c. Read the comment docs.
Andy Massimino
@prabirshrestha, can you explain further how having the items field would allow a plugin to implement fuzzy search?
Prabir Shrestha
@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.
Bram Moolenaar
> @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': ''})
I don't think it is needed to use a dictionary argument. We can use a
list of strings, that is simpler:
" 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'])
hundred-and-one symptoms of being an internet addict:
nor the address where you live.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Prabir Shrestha
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.
h_east
@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.
h_east
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.
Bram Moolenaar
> @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
The getqflist() function has some arguments with a number value. E.g.
"nr" specifies the quickfix list. For complete_info() I don't think we
would ever have a number value, only a list of items to return.
I think that consistency between these two functions is not relevant.
--
hundred-and-one symptoms of being an internet addict:
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Yegappan Lakshmanan
On Sun, Mar 17, 2019 at 6:44 AM Bram Moolenaar
<vim-dev...@256bit.org> wrote:
>
>
> > @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.
>
> The getqflist() function has some arguments with a number value. E.g.
> "nr" specifies the quickfix list. For complete_info() I don't think we
> would ever have a number value, only a list of items to return.
>
arguments in {what}:
id quickfix list identifier
lines List of lines to parse
efm Error format to use for parsing the list of lines in 'lines'
nr quickfix list number
As the caller can pass non-zero values for these items, the
getqflist() function uses a Dictionary instead of a List as the
argument type.
- Yegappan
vim-dev ML
Prabir Shrestha
Update 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?
—
You are receiving this because you commented.
h_east
@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)
—
You are receiving this because you commented.
mattn
@prabirshrestha @brammool If you have opinion about this patch, pleaes let me known. I'll take over the work.
—
You are receiving this because you commented.
Prabir Shrestha
It is ready to be merged from my side.
—
You are receiving this because you commented.
Prabir Shrestha
@brammool Any update on this? Any concerns blocking the merge to master?
—
You are receiving this because you commented.