Community
Participate
Working Groups
Build Identifier: e.g. in Java when I have typed "ByteArrayInputStream bis=new " It would be very nice if the autocomplete knew that I was very likely to want a new ByteArrayInputStream rather than just any class. Certainly I might not want that, but if I hit CTRL+SPACE at this point it's clear what I'm asking for. Thanks! DrTune Reproducible: Always Steps to Reproduce: 1. When editing any java method, type "ByteArrayInputStream bis=new " 2. Hit CTRL+SPACE 3. See that list of /all/ classes is presented; surely the obvious is a new "ByteArrayInputStream" - that should be default choice, with all the others presented below as normal.
I know this is really minor but the fact that it's now irritated me for the 50-somethingth time prompted me to come ask for it. If I had more time I'd learn the codebase and do it myself, sorry I don't. Thanks for an amazing tool, in 25 years of geeking it's my fave IDE.
(In reply to comment #1) > I know this is really minor but the fact that it's now irritated me for the > 50-somethingth time prompted me to come ask for it. If I had more time I'd > learn the codebase and do it myself, sorry I don't. Thanks for an amazing tool, > in 25 years of geeking it's my fave IDE. What is your build id ? On 3.6M7 ByteArrayInputStream is proposed ahead of others, as you indicate you want. Can you try with the latest (i.e 3.6M7) and report if this is still an issue ?
Ayush, please follow up.
Build id: 20100218-1602 My apologies you are absolutely correct; It works perfectly *IF* the class is currently in the java file's imports, i.e. is in scope. If the class has not yet been added to the java file's imports, the behavior is as I described. I am lazy and use "autofix" to add my missing imports after I've typed my code (as do most people I expect), which is why I experience this minor issue. I won't suggest you try to autocomplete based off all possible classes in the library path because it's insane. --possible suggestion May I suggest that if the class I'm creating is unknown to the editor that it just copy what the definition is. This implies that I could type "SomeClassThatDoesntExist newclass= new " and the editor would a) try to find the class in the current way (within current file and import scope) and not find it. b) give up and simply suggest back to me my (non-existent) class as the default option. I appreciate this is not how your normal autocomplete works b.c you expect to have a real class description (with argument list) etc to work off. Many thanks, I'd be totally happy if you close this and say "Not a bug".
(In reply to comment #4) Hi drtune > Build id: 20100218-1602 > It works perfectly *IF* the class is currently in the java file's imports, i.e. > is in scope. Thanks for verifying this. :) > I am lazy and use "autofix" to add my missing imports after I've typed my code > (as do most people I expect), which is why I experience this minor issue. I understand that you rely on autofix to add the missing import for you. Doing that should actually to solve your problem in this case as well. So when you type SomeClassThatDoesntExist newclass= new Autofix would immediately suggest adding the missing import. You can go ahead and and do that. Once this is done using CTRL-SPACE after new will give you your required proposal. It is indeed a break in the typing flow, but an unavoidable one i guess. > --possible suggestion > "SomeClassThatDoesntExist newclass= new " > > and the editor would > a) try to find the class in the current way (within current file and import > scope) and not find it. > b) give up and simply suggest back to me my (non-existent) class as the default > option. Content assist cannot, per se, suggest a 'non-existent' class or even any other piece of code. It relies on the compiler to find out all possible completions, and only resolved code qualifies to be a completion. Thats why until you have the import in place, it doesnt make sense for us to make random guesses. I believe correctness cannot be compromised for the sake of convenience. A correct proposal after new should be a constructor, and unless we have the import in place, content assist can't guess the constructor on its own. Drtune, hope this is satisfactory. Do let me know what you think. This bug should be closed as WORKSFORME.
(In reply to comment #5) > (In reply to comment #4) > Hi drtune [...] > Drtune, hope this is satisfactory. Do let me know what you think. This bug > should be closed as WORKSFORME. My suggestion is to keep this open, the request is a reasonable one. The presence or absence of import statement is not germane to this case: See that constructor proposal works ok in this case (without the import) public class Test extends Thread { public void method() { ByteArrayInputStream bis = new ByteA| } } Parts of the current implementation get triggered only when there is a non empty prefix to the type name after "new". In the presence of a clear expected type on the LHS, we can perhaps relax this somewhat and make meaningful proposals for the case originally reported by Drtune ?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > Hi drtune > > [...] > > > Drtune, hope this is satisfactory. Do let me know what you think. This bug > > should be closed as WORKSFORME. > > My suggestion is to keep this open, the request is a reasonable one. You have two workarounds: (1) Use code assist to insert the type name on the LHS in the first place. (2) Use completion in the following form: ByteArrayInputStream bis = new BAI| (type ctrl+space in place marked with |)
This scenario illustrates the problem best: public class Test extends Thread { public void method() { ByteArrayInputStream bis = new B| } } Completing at the position marked with |, proposes ByteArrayInputStream's constructors alright, but these show up way way down (after hundreds of others). So we should boost the relevance of BAIS's ctors by using the notion of expected type from the LHS. Ayush, see what is the behavior here when new is followed by a subclass's prefix as well to see if our behavior is reasonable.
(In reply to comment #8) > This scenario illustrates the problem best: > > public class Test extends Thread { > public void method() { > ByteArrayInputStream bis = new B| > } > } I agree. If we can suggest the constructor here with one token - B, we should be able to do it without any token as well. Also relevance has to be boosted up. Will have to investigate on both these fronts.
(In reply to comment #8) > Ayush, see what is the behavior here when new is followed by a subclass's > prefix as well to see if our behavior is reasonable. The behaviour is similar with subclass as well.
Wow I never, ever expected such prompt and detailed service. Two things I've learned today that I didn't know: a) you could abbrebiate the autocomplete with capitals ("BAIS") b) that if you autocomplete on the initial part that the import is silently added, and hence the "= new " autocomplete then works exactly right. Thanks I'm totally happy. You've shown me how to reduce my keystrokes to: "BAIS[ctrl+space][return] bis=new [ctrl+space][return]([return];" ..and that saves me time and solves my request. --praise You guys and the product you've worked so hard on are amazing. I never cease to be impressed by Eclipse and use it 8+hrs a day on many platforms for C and Java for GCC, J2ME, Android, Tomcat, Embedded stuff, etc. Eclipse is the clear winner as "The Universal, Free IDE", and is the unarguable choice for anyone that needs to put together a developer tool. This is nice because now the human race can get on with other stuff. You must be very proud. Thanks! DrTune.
The feedback provided by Eclipse team was great; I was educated in my use of the editor. Thank you.
Verified for 3.7M2 using build I20100909-1700
