Community
Participate
Working Groups
I'm trying to create a method that contains an ellipsis parameter. But when trying to enter the triple dot, code completion is performed. This results in changing the desired type to a sub-type and not an ellipsis. Might be related to Bug 478246.
(In reply to Dirk Fauth from comment #0) > I'm trying to create a method that contains an ellipsis parameter. But when > trying to enter the triple dot, code completion is performed. This results > in changing the desired type to a sub-type and not an ellipsis. you mean 'nested type' rather than subtype, right?
Yes nested type. Sometimes also accessible fields are added, for example if there is no nested type. Typing the triple dot almost everytime produces something unwanted.
(In reply to Dirk Fauth from comment #0) > I'm trying to create a method that contains an ellipsis parameter. But when > trying to enter the triple dot, code completion is performed. This results > in changing the desired type to a sub-type and not an ellipsis. > > Might be related to Bug 478246. Please provide a concrete example using plain Eclipse SDK 4.6 M6: http://download.eclipse.org/eclipse/downloads/drops4/S-4.6M5-201601282000/
I think M6 is hard to get. ;-) So I tried with the linked M5 and actually I needed some time to find the setup to reproduce the issue. First update your preferences to include Java to the auto-completion: Window -> Preferences -> Java -> Editor -> Content Assist -> Advanced Check "Java Proposals" BTW, why are they disabled by default? I would have assumed that Java Proposals are enabled by default for a Java editor. Or do I misunderstand the content assist feature? Then create a class similar to the following snippet. The key for the reported issue is the public static nested class. public class Test { public InnerTest bar; public static class InnerTest { public String bar; } } If you now try to create a method in another class that takes Test as ellipsis parameter, you will immediately get Test.InnerTest.. as result. I assume this is related to activating auto-completion by pressing a . with 0 ms delay.
(In reply to Dirk Fauth from comment #4) > First update your preferences to include Java to the auto-completion: > Window -> Preferences -> Java -> Editor -> Content Assist -> Advanced > Check "Java Proposals" > BTW, why are they disabled by default? I would have assumed that Java > Proposals are enabled by default for a Java editor. Or do I misunderstand > the content assist feature? If you had to do that then you did not use a new workspace and the indicated build. Those are checked by default. But unchecked in the lower (cycling) section. > Then create a class similar to the following snippet. The key for the > reported issue is the public static nested class. > > public class Test { > > public InnerTest bar; > > public static class InnerTest { > public String bar; > } > } > > If you now try to create a method in another class that takes Test as > ellipsis parameter, you will immediately get Test.InnerTest.. as result. I can reproduce it now. > I assume this is related to activating auto-completion by pressing a . with > 0 ms delay. Yes, and the fact that the second dot inserts the proposal. See also bug 348857.
(In reply to Dani Megert from comment #5) > (In reply to Dirk Fauth from comment #4) > > First update your preferences to include Java to the auto-completion: > > Window -> Preferences -> Java -> Editor -> Content Assist -> Advanced > > Check "Java Proposals" > > BTW, why are they disabled by default? I would have assumed that Java > > Proposals are enabled by default for a Java editor. Or do I misunderstand > > the content assist feature? > > If you had to do that then you did not use a new workspace and the indicated > build. Those are checked by default. But unchecked in the lower (cycling) > section. I used the indicated build, but indeed an existing workspace. You are right that it is checked using a new workspace.
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.
The bug can still be reproduced using the example from comment 4 and then typing somewhere else void m(Test... result is void m(Test.InnerTest..) Not good. Checking the following option (from bug 348857) can be used to work around the problem: [x] Disable insertion triggers except 'Enter' That option might be worth advertising more widely.
Another workaround: press "." then Esc, then ".." The problem is with the Java Type Proposals. Maybe a workable solution would be to offer as a first proposal "... ellipsis", if content assist is invoked within an argument list and enabled by auto-activation trigger ".".
(In reply to Dirk Steinkamp from comment #10) > Another workaround: press "." then Esc, then ".." > > The problem is with the Java Type Proposals. Maybe a workable solution would > be to offer as a first proposal "... ellipsis", if content assist is invoked > within an argument list and enabled by auto-activation trigger ".". Wouldn't that just change one undesired result to another result that may be undesired as well. I.e., if you intend to type "Test.InnerTest" you would not be able because that sequence of keys would get you "Test... InnerTest", no? I don't think that the concept of auto-activation including '.' can be repaired in a situation where '.' introduces syntactical ambiguity. The auto-activation mechanism would need to dive into semantic analysis to decide if what's left of the cursor is ambiguous or not (if ambiguous: don't insert). Doing semantic analysis at this point may be a violation of tool architecture, which would minimally introduce a performance problem. As a compromise I could imagine that auto-activation could be suppressed withing any parameter list. Perhaps syntactical context-awareness might be achievable. Any enthusiast for auto-activation interested in giving this idea a try?
