Community
Participate
Working Groups
In the snippet below, I'd like to get a proposal list as soon as I press ctrl-space at the | point (within a method invocation round brackets). Currently, I need to enter at least one char before invoking content assist. (trivial here, that I'd need something that starts with p or 'l', think of an ugly large class with ugly long methods ;-) The proposals shown with the 'guess argument option', when content assist inserts the method, is just the proposal I'd love to see when invoking content assist myself within the method invocation round brackets. public class ContentAssistTest { public void doSthg(Object p1, Object p2, String p3) { Object l1, l2, l3; doMore(|) } void doMore(Object arg) { } }
Yes, I would also find that more natural than the current behavior. David, that's along the discussion we had last week. Martin feels the same about this.
This is strange behavour compared with content assist on assignment, where it works quite fine: public class AutoComplete { final static int VALUE = 1; int method(int index) { return index; } void test() { int index = 20; int vv = /*cc1*/; method(/*cc2*/); } } press Ctrl-Space before the marked area: /*cc1*/ - eclipse correctly suggests 'index', 'VALUE', 'hashCode', ... /*cc2*/ - eclipse suggest nothing, but it should suggest the same as for cc1 (+ 'v')
can this be considered for 3.6 ?
actually in 3.6M2 the behavior is such that l1,l2,l3mp1,p2,p3 are shown ... if I invoke content assist after I have entered at least one dummy char, for example a dot (also a comma etc). Not intuitive as i will then have to delete the dot if I accept the content assist suggestion.
I came here to add a request for this feature and found this old report. I can confirm that this is still very much a problem in Juno.
I am the original requeser and would ove to see this fixed. It is still annoying in Juno to have to type something after the open bracket - even a useless dot - before content assist is shown.
I'll take this.
My guess: everything is already there, but we don't propose things if there's no prefix. We usually do this for performance reasons.
(In reply to comment #8) > My guess: everything is already there, but we don't propose things if > there's no prefix. We usually do this for performance reasons. Hi Daniel, if the prefix is a dot (which is not a valid identifier start) the suggestions are shown anyway inside a a methods call arguments. Outside of a methods call arguments, no prefix is necessary.
(In reply to comment #9) > Hi Daniel, > if the prefix is a dot (which is not a valid identifier start) the > suggestions are shown anyway inside a a methods call arguments. > Outside of a methods call arguments, no prefix is necessary. I know that, but thanks.
Thank you very much for looking into this again. What about overloads? void method(String s, int i) { System.out.println("si"); } void method(String s, String s2) { System.out.println("ss"); } void active() { String s1, s2; int i1, i2; method/*cc1*/ method(/*cc2*/) method(s1, /*cc3*/) } *cc1* Works really well - asks which overload I prefer and walks though the completion *cc2* Should this just complete strings (since it can be inferred that a String is always wanted) or should it pop up the 'overload chooser'? *cc3* Same question. Should this show both integers and strings or should it show the popup first?
(In reply to comment 9 and comment 10) That you get proposals when you type a '.' after the '(' is an implementation artifact (you could also say it's a bug). It doesn't make sense as a design choice, and I guess it just happens by chance since the AST recovery removes the '.', but the content assist sees a non-empty prefix and automatically opens the proposal popup on '.'. You also get proposals if you type an other character ('?', ';', '-', etc.) and then press Ctrl+Space.
This is pretty annoying, also affects jdt.ls/vscode-java users[1]. Any pointers on how to fix it? We (Red Hat) *might* be able to contribute a fix for this. [1] https://github.com/redhat-developer/vscode-java/issues/549
There's a check in CompletionParser#completionIdentifierCheck() that look for checkInvocation(), but along with "!isEmptyNameCompletion() || ". What we need for this bug is to change that "or" to "and". This could be good starting point but could lead to other issues since this behavior appears to be intentional.
(In reply to Jay Arthanareeswaran from comment #14) > There's a check in CompletionParser#completionIdentifierCheck() that look > for checkInvocation(), but along with "!isEmptyNameCompletion() || ". What > we need for this bug is to change that "or" to "and". This could be good > starting point but could lead to other issues since this behavior appears to > be intentional. Sorry, looks like it's not as simple as that. We are looking at presenting both cases of completion for method invocation as well as method arguments, which seems to complicate things with the current code. One option is to look for the closing ')' and if it's present, offer identifier otherwise, present the method invocation and like.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
