Re: [cdt-dev] Code completion: Handling parentheses the smart way

[Roman Levenstein <romixlev@xxxxxxxxx>]

Hi Norbert,

see my inline comments below.

Regards,
 Roman

> another issue with code completion proposals
> supplied from an ICHelpProvider: 
> The only way to return proposal information is
> through an array of 
> IFunctionSummary objects. Now I want to return
> information also for 
> non-function items like global variables, types,
> enums etc. I can make it fit 
> on the whole even though IFunctionSummary and
> IFunctionPrototypeSummary 
> obviously assume that help should be supplied for
> functions only. 

I also noticed this issue. Though it can be fit into
IFunctionSummary, I think that continuing using
IFunctionSummary for all different kinds of
information is just a bad design. I think it would be
better to introduce a base class that keeps a generic
information about the symbol (e.g. kind of symbol,
description, required includes, etc) and have derived
classes for functions, variables,  types, classes, etc
with the specific fields. The disadvantage is that we
have to change current API and extend the class
hierarchy. But if the current design is not so good
any way, and since nobody seems to use the CDT help
facilities really extensively, let's change it. Not so
many people and code will be affected and we will have
a more powerful help system. 

> But when I pick the suggestion from the completion
> proposal list it always 
> gets parentheses () appended at the end. This is
> hard-coded in 
>
HelpCompletionContributor.contributeCompletionProposals().
> A pair of 
> parentheses is always appended to the (function?)
> name. For my purposes I 
> need a smarter handling of parentheses. I see two
> ways to mend this:
> 
> 1) Change the API description (not the code) of
> IFunctionPrototypeSummary so 
> the the method getArguments() returns
> - the empty string for an empty parameter list
> - null for no parameter list, i.e. this is not
> information about a function at 
> all.

  Well, it would work. But it is clearly a hack. And
I'm pretty sure that in the future, for advanced
use-cases, it will not solve all of our problems. And
we will need to add some further hacks on top of it.
So, let's do it properly right from the beginning. 
 
> 2) Give IFunctionSummary an additional such as an
> int getKind() method which 
> can return information (static final int constants)
> about the item that is 
> being described. HelpCompletionContributor can use
> the information to 
> determine whether or not to append the parentheses
> pair
> This of course would be an API change

See my comments above. I think it is a cleaner and
more future proof way to do it. 
 
> What do you think? Any other suggestions? The code
> change is minor, agreeing 
> on the way to handle this is important. Let's make
> the help provider fit to 
> do much more than what it was designed for!




		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com