Bug 366402

Comment 1 Lars Vogel 2011-12-13 04:24:16 EST

Would be great if I would use this to create method overrides, e.g.

I have a method public void onLongButtonClicked() in my super class

I type clicked press CNTR+Space and I have the option to override the method from above.

Comment 2 Marcel Bruch 2011-12-15 00:13:10 EST

Subwords support for override proposals is supported in 0.5 branch.

Subwords support for type names is not yet implemented.

Comment 3 Steve Ash 2011-12-27 16:12:06 EST

I went through this code and think I understand the roadblocks now.  Wanted to put some info here for any future readers and to get Marcel's opinion on whether I should pursue this at the moment or not.

As described here (https://bugs.eclipse.org/bugs/show_bug.cgi?id=350000) type proposals are not being included currently as the strategy of the current subwords completion is delegate the completion request to JDT's completion engine on the compilation unit _as if_ the user had hit <ctrl+space> after the dot.  This returns back a large list of every option, then filter that list with a regular expression using the characters typed after the dot.  

The problem is the JDT's completion engine doesn't return type info without at least one prefix character being entered.

The idea was to use the JDT SearchEngine system to get all types that satisfy the wildcarded string and present those.  i.e. we could take the "token" after the dot, create a "wildcarded string" (with lowercase'd characters) and submit that to the SearchEngine.  

So typing:
trng<ctrl+space>

would submit a query to SearchEngine for "*t*r*n*g* and then present those results.

A few concerns:
1) 
How to know when to do this extra step?  We only want to propose type options when the target of the autocomplete is a type.  

Without the functionality in https://bugs.eclipse.org/bugs/show_bug.cgi?id=340945 Im not sure how to do that.  I believe that Recommenders already has their own AST parsing, and thus I could base it on that, but it seems that 340945 is close so I don't want to do a bunch of work for no reason.  I see that 340945 has been committed to JDT head, but I can't seem to figure out how best to get that into my environment so that I can test it.

2) 
Performance?  I have serious concerns about the performance of this.  I was thinking to create the SearchEngine insteance from the compilation unit so that only reachable types would be considered.  Should these be cached? etc. 

3) 
JDT's type completion doesn't seem to use the SearchEngine interface.  I tried following what JDT was doing but it seemed very complicated -- it was very "woven" into the AST model it seemed, and I just don't have enough background to understand it.  

4) 
Utility of these types being offered.  If I run "Open Type" and type *t*r*n*g* right now I get maybe about 2200 types presented to me with very few of these actually being "likely" (from a markov perspective).  Is that even valuable?  I know that we can't resort either once the original completion is computed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=346947).  So I would worry that the noise is too great and outweigh the benefit.

Just some thoughts.  I can certainly appreciate why this is not on the roadmap for this year although I would like it to be as I have serious IntelliJ auto-complete envy.

Comment 4 Steve Ash 2011-12-27 16:15:24 EST

Oh also as a minor side note, there is a minor performance improvement that might be gained by precompiling the regex in the SubwordsCompletionProposal constructor and just using that one instead of recompiling the same regex every time (which is what happens right now in the SubwordUtils call for each candidate result from JDT).

Comment 5 Marcel Bruch 2011-12-27 19:03:47 EST

Hey Steve, you got all necessary details right!
(In reply to comment #3)
> would submit a query to SearchEngine for "*t*r*n*g* and then present those
> results.

> A few concerns:
> 1) 
> How to know when to do this extra step?  We only want to propose type options
> when the target of the autocomplete is a type.

Right. The new completion context is available in M4. Thus, we can use it. Than we just have to check the completion node type whether we are interested in this kind of Completion.

> 2) 
> Performance?  I have serious concerns about the performance of this.

I do so too. But we have to try before we optimize. Also, JDT guys may assist here if we get it running soon. Don't optimize until it all works :)
 
> 3) 
> JDT's type completion doesn't seem to use the SearchEngine interface.

Right. Ayushman recommended us to use the search interface. Let's try the search engine first. If we hit a problem we'll get back to Ayushman and Dani.

> 4) 
> Utility of these types being offered.  If I run "Open Type" and type *t*r*n*g*
> right now I get maybe about 2200 types presented to me

I see the problem. It will be an art to present the 'right' ones on top :) What do you think? Let's postpone this discussion until we have a working prototype? In addition, if Intellij has it and you love it - it seems to be valuable.

> I can certainly appreciate why this is not on the roadmap
> for this year although I would like it to be as I have serious IntelliJ
> auto-complete envy.

Let's go for it then :)

Comment 6 Marcel Bruch 2011-12-27 19:07:13 EST

(In reply to comment #4)
> Oh also as a minor side note, there is a minor performance improvement that
> might be gained by precompiling the regex in the SubwordsCompletionProposal
> constructor and just using that one instead of recompiling the same regex every
> time (which is what happens right now in the SubwordUtils call for each
> candidate result from JDT).

I agree that this would be more efficient. Did you notice any performance decreases? If it becomes too slow we have to fix it. But if no one notices a performance bottleneck, it's not a bottleneck :)

Comment 7 Marcel Bruch 2012-02-22 03:04:00 EST

Brief update:

As of v0.5 subwords should be able to work as a replacement for standard java code completion, i.e., it should make the same completions as JDT would do but also works for non-prefix matches.

It supports method override completion, call completions, and completion on variable names. It still does not support completion on type names.

Comments on the new behavior and patches welcome.

Comment 8 Marcel Bruch 2012-03-02 04:08:45 EST

(In reply to comment #4)
Hi Steve, the unsupported "type" proposals start annoying me ;) Did you find some time to work on this? If so, it would be great if you could share your current state with us.

Thanks,
Marcel

Comment 9 Marcel Bruch 2012-04-23 02:19:07 EDT

The current solution now has limited support for  type names and variables in method arguments. It requires a prefix match before triggering (e.g, you have to enter 'S' before triggering to get all type proposals starting with 'S'. From then you can use subwords as usual).

This is not a perfect solution but given that we are running out of time, I think it's an acceptable solution for Juno. I'm closing this plan item now but created a new one for the type completion (Bug 377373).

Comment 10 Marcel Bruch 2012-06-09 15:11:39 EDT

Set target milestone for fixed bugs to 1.0

Comment 11 Marcel Bruch 2012-06-09 15:11:59 EDT

Set target milestone for fixed bugs to 1.0