Eric van Dewoestine wrote:

> Have you spent any more time considering this?  I really feel that it
> is important to provide the flexibility to the plugin developers to
> display completion result as they see fit.  In my case I want to be
> able to pass this flexibility on to the users so that they can decide
> which model THEY most prefer.
> 
> I took your advice about displaying all available method signatures
> within the 'info' of a single completion entry and it works quite well
> unless:
> a) the user doesn't have 'preview' in their 'completeopt'
>   - If the user doesn't have 'preview' enabled then they never get to
> see all the available method signatures. Putting then all into 'menu'
> isn't practical since 'menu' is truncated upon rendering.
> b) the time comes where 'info' can be used for real method documentation.
>   - If / When vim provides a means for lazy loading of 'info' (hint
> hint ;) ), then I want to be able to put the full method docs into the
> 'info' field, and putting the full docs for all overloaded methods
> could make the 'info' quite large and cumbersome to navigate.
> 
> Since the two above conditions potentially invalidate the usefulness
> of compacting overloaded methods into a single entry, I provide the
> user with the option to choose what they want displayed in their
> completion results:
> 1) standard - each overload method has its own entry in the completion resu=
> lts
>   (limited now by the default removal of duplicates... which I'm
> hoping you will consider removing).
> 2) compact - overloaded methods are represented as a single entry with
>   menu: 'Overloaded, see preview...'
>   info: 'someMethod (String)\nsomeMethod (String, String)...
> 
> I really think vim's code completion is close to rivalling that of the
> IDEs, but only if the plugin developers are empowered to make their
> own decisions without vim dictating what it deems should be correct
> for every situation.

The completion stuff already is very complicated.  Adding fancy things
is going to take lots of time and introduce new bugs.

Allowing duplicate entries is not that difficult.  Perhaps adding an
item to the dictionary for this is sufficient.  Let's use "dup" for
that.

-- 
DINGO:   And after the spanking ... the oral sex.
GALAHAD: Oh, dear! Well, I...
GIRLS:   The oral sex ...  The oral sex.
GALAHAD: Well, I suppose I could stay a BIT longer.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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