On 4/20/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Eric Van wrote:
>
> > Code Completion suggestion.
> >
> > Ok, first a little context.
> > I currently have a project which provides an interface for vim to
> > invoke commands via system() calls which are executed in a headless
> > eclipse instance.
> >
> > I use this interface to provide code completion for java source files
> > and ant build files, which both work great. My issue comes into play
> > when I attempt to provide completion info (for display in the new
> > completion preview window in vim). Retrieving this extra info can
> > result in a lot of extra processing on the eclipse side and depending
> > on the size of the completion set, can dramatically affect the
> > performance.
>
> Most of this should already be possible using complete_add() and
> complete_check(). See below ":help complete-items".
Unfortunately not, since I'm using a system() call, so I get all the
results at once.
>
> > So, I propose a means to lazily retrieve info for a completion.
> > Basically it should be like a CursorHold, but in the context of the
> > completion popup. If the user stops on a completion for some
> > determined amount of time, vim should then, ideally, spawn off a
> > thread to retrieve the info for that completion and display it in the
> > completion preview. I think it is key to do this retrieval in an
> > asynchronous way so as not to prevent the user from moving to the next
> > completion or performing some other action.
>
> Using threads is a difficult thing to do in a portable way. Vim is
> build with threads in some situations (e.g., when using the Python
> interface) and this often causes problems. On some systems threads are
> not possible.
That's probably fine since retrieving the info for a single completion
should be quick... it's retrieving info for many that can be slow.
>
> > To accomplish this, I also suggest that the means for defining how
> > completion is to be handled, be modified.
> >
> > Currently completion is defined as follows:
> > setlocal completefunc=3DSomeFunction
> >
> > With a single function
> > function SomeFunction (findstart, base)
> >
> > Instead of defining a single function, I propose that a script be
> > defined instead:
> > setlocal completescript=3Dfoo/bar/mycompletion.vim
> >
> > Where the script is located via the autoload directory and contains
> > the following functions (of which the first 2 are required, and the
> > third is optional)
> >
> > " find the column in the current line where the completion starts
> > function foo#bar#FindCompletionStart ()
> >
> > " find the list of completions given the supplied base.
> > function foo#bar#FindCompletions (base)
> >
> > " find additional info for the completion at the supplied index
> > " within the current completion results
> > function foo#bar#FindCompletionInfo (index)
> >
> > If implemented in this fashion, you gain a few advantages:
> > 1. Completion info is only retrieved for completions that the user
> > chooses to view and not for the possibly many others for which the
> > retrieval would have been completely wasted.
>
> This will break the use of the completion menu. It's better to have all
> possible completions, so that the user knows how many possibilities
> there are. Since Vim checks if the user typed something while it's
> still searching this should not be a disadvantage.
Maybe I didn't explain this correctly... I would expect the flow to be
- User hits <C-X><C- O or U>
- vim executes foo#bar#FindCompletionStart instead of
CompletionFunction(1, '...')
The starting column of the completion is returned.
- vim executes foo#bar#FindCompletions('...') instead of
CompletionFunction(0, '...')
The FULL list of completions is retuned, but in this case the 'info'
attribute of the contained dictionaries is empty (since they would
be lazily retrieved later, only when needed)
- User stops on a completion for a determined amount of time
- vim then executes foo#bar#FindCompletionInfo(index), where index
is the index of completion the user paused on.
- vim displays the that info in the preview window
When using netbeans or eclipse this lazy loading of the 'info' text is
very apparent (especially in netbeans). As you navigate down the
completion menu, the info loads only after you have paused on an entry
(eclipse in about half a second, netbeans in about a second and a half).
>
> > 2. More optional functions could be added to this completion script in
> > the future without breaking compatibility with previous releases.
> >
> > While I'm at it another suggestion I have would also to be to add
> > another function to my proposed script paradigm:
> > function foo#bar#FindCompletionEnd ()
> > Which would find the ending column of the word to be replaced by the
> > completion. So if I am have the following ('|' denoting the cursor
> > position):
> > List mylist = ...
> > mylist.ad|d(
> > The 'd' after the cursor position could be replaced when I choose
> > amongst my choices of 'add' or 'addAll', instead of having to manually
> > delete it after exiting the completion mode.
>
> Completion always works on the text before the cursor. The completion
> function can always include some text if it wants to. But changing text
> after the cursor is not what the user expects.
Actually, this depends... Eclipse provides the option to 'insert' or
'overwrite' when completing within a word like I showed above. It
defaults to 'insert', but some users, myself include, may want to
overwrite.
--
eric
