Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] code assist and overloaded operator methods

On Thursday 29 May 2014 17:45:42 Nathan Ridge wrote:
> >>> Another check that I would find reasonable is for the prefix op.
> >> 
> >> One property of code assist is that as the length of the prefix
> >> increases, the number of results decreases.
> > 
> > well, if you don't count macro handling ;-)
> 
> What do you mean?
from DOMCompletionProposalComputer
// handle macros only if there is a prefix
handleMacros = prefix.length() > 0;
> 
> >> I think users would find it counterintuitive to break this property.
> >> For example, I think it would be unexpected if a list of completions
> >> for the prefix 'o' did not include operators, but for 'op' it did.
> > 
> > And my reasoning would be if I look for overloaded operators that I would
> > certainly start with a prefix (whether it be o or op is debatable)
> > On the other hand starting with an empty prefix, I would assume you're
> > somewhere in the woods and need some serious help. More is not always
> > better .... from my experience.
> 
> I guess one could argue that an empty prefix is special. It feels slightly
> less strange for operators to appear when going form empty to 'o', than
> when going from 'o' to 'op'.
> 
> I'd still prefer having the operators around with an empty prefix, at the
> end of the list. I don't see them doing much harm there.
I agree.
> 
> Another possibility would be a preference  to exclude operators from
> code assist results.
> 
> > But are we on the same page if I say this applies to objects only and
> > dealing with CPPASTQualifiedName is a different story?
> 
> Could you give an example? I think if we have a type name followed by ::,
> we already don't offer operator results.
funny, now I can't reproduce it. And I thought I had found a pattern .....
I will further investigate how that could happen. At least I know that it must 
be a bug.

thanks so far
Michi
> 
> Regards,
> Nate
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top