Bram, 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 results (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. I appreciate you taking the time to read and consider this, and please let me know your thoughts on the subject. thanks
