Delayed suggestions & unwanted suggestions about asyncomplete-buffer.vim HOT 3 CLOSED

Hey @xtal8 I am taking a look at this.

an updatetime=1 would fire the cursorhold event every 1ms which seems a bit overkill here.
http://vimhelp.appspot.com/options.txt.html#%27updatetime%27

I don't think the behavior of the CursorHold event is the problem here. It seems to me like we have 2 other issues:

1. There is no cache invalidating. After we cache these words we never remove them.

2. While actively working(without saving), the only event we have that triggers is TextChangedI. From the description at http://vimhelp.appspot.com/autocmd.txt.html#TextChangedI it seems like this would be sufficient, but maybe there are other events which would work here.

from asyncomplete-buffer.vim.

This is because the TextChangedI causes the buffer source to refresh waaayyyy too often. After #4 is merged, you can override the events in your source registration in .vimrc with something like this:

au User asyncomplete_setup call asyncomplete#register_source(asyncomplete#sources#buffer#get_source_options({
	\ 'name': 'buffer',
	\ 'whitelist': ['*'],
	\ 'blacklist': ['go'],
	\ 'events': ['TextChanged','InsertLeave','BufWinEnter','BufWritePost'],
	\ 'completor': function('asyncomplete#sources#buffer#completor'),
	\ }))

#2 could be solved by this, as well.

from asyncomplete-buffer.vim.

There is no cache invalidating. After we cache these words we never remove them.

This also means that asyncomplete.vim pulls matches from every buffer you've opened in the current Vim session, rather than just the active buffer.

from asyncomplete-buffer.vim.