I have written a custom completion function that I wanted to use with autocomplpop.vim, and encountered some minor bugs that prevented the integration. I'm sharing the bugfixes and enhancement with you in the hope that you incorporate them into your script, as these aren't hacks required for my plugin, but general (though apparently rare) issues.
My completion function "MinLengthComplete" only offers completions that add more than n characters:
> The built-in insert mode completion |i_CTRL-N| offers any completion
> matches, even ones that only add nothing or only a few characters, which can
> often be inserted more quickly by just typing the characters than browsing
> through the completion list.
> This plugin offers a custom completion function that only offers
> "worthwhile" matches that add at least n characters. It uses a backward
> |i_CTRL-P| search, so that previously typed words are offered first.
(Note: This plugin hasn't yet been released, but I may plan to publish it on vim.org if you approve of my changes.)
Here's the list of changes to autocomplpop.vim:
- BUG: When the configured completion is <C-p> or <C-x><C-p>, the command
to restore the original text (in on_popup_post()) must be reverted, too.
While experimenting with backwards-completion (<C-p>) to get preceding words offered before following words, I found out that the popup menu doesn't work correctly in these cases. I added a check in s:PopupFeeder.on_popup_post().
- BUG: When using a custom completion function (<C-x><C-u>) that also uses
an s:...() function name, the s:GetSidPrefix() function dynamically
determines the wrong SID, because it is called from that surrounding context.
Now calling s:DetermineSidPrefix() once during sourcing and caching the value
The pattern in s:GetSidPrefix() is too broad; one could fix this by changing the pattern to
> return matchstr(expand('<sfile>'), '<SNR>\d\+_\zeGetSidPrefix')
Instead, I optimized further and looked up the SID only once during sourcing, using a cached s:SID value from then on.
- BUG: Should not use custom defined <C-X><C-...> completion mappings.
Now consistently using unmapped completion commands everywhere.
(Beforehand, s:PopupFeeder.feed() used mappings via feedkeys(..., 'm'),
but s:PopupFeeder.on_popup_post() did not due to its invocation via
In my vimrc, I have mapped all <C-n>, <C-x><C-f>, ... mappings to do some additional magic like pre-selecting the first match. That clashed with autocomplpop. In fact, autocomplpop partially uses the mappings, partially not. Since mappings cannot be used consistently in all places (in a :map <expr>, the returned <expr> is always executed as-is without remapping), I instead split the feedkeys() in s:PopupFeeder.feed() so that the completion command is *not* mapped, but the <Plug>AutocomplpopOnPopupPost must be mapped.
- ENH: Added support for setting a user-provided 'completefunc' during the
completion, configurable via g:AutoComplPop_Behavior.
Auto-completion should not change the default 'completefunc'. Using the existing s:OptionManager, the value of 'completefunc' is temporarily overwritten during the auto-completion. If it were possible to consistently allow mappings for completion (see point above), one could alternatively do without this new option, and configure custom mappings for that. I actually prefer this new option, it makes it clearer which user-completion is actually used.
I'm attaching a diff against autocomplpop.vim 2.6.
-- kind regards, ingo
-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
-- http://vim.sourceforge.net/account/profile.php?user_id=9713 --