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".

> 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.

> 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.

> 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.

-- 
hundred-and-one symptoms of being an internet addict:
212. Your Internet group window has more icons than your Accessories window.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://www.ICCF.nl         ///

Reply via email to