Bugzilla – Full Text Bug Listing
| Summary: | [content assist] Shows invalid proposals | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Nobody - feel free to take it <nobody> |
| Component: | Core | Assignee: | JDT Core Triaged <jdt-core-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | Ayushman Jain <amj87.iitr> |
| Severity: | normal | ||
| Priority: | P3 | CC: | aboyko, amj87.iitr, remy.suen, srikanth_sankaran |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | stalebug | ||
With this above example, content assist gives you the (public) constructors for ByteArrayInputStream at the top of the list, and some other constructors after that. Do you mean that you dont see constructor for ByteArrayInputStream at all? Or are you saying that we should only show constructors for ByteArrayInputStream and its subclasses and not show the other results? Extra proposals in content assist are usually not evil - they give the user some flexibility and incase he realises that he did not want to create a ByteArrayInputStream object, but say some ByteArrayInputStream2 object, he can still chose the constructor for that and go back and make a change to the declared type. If the proposal was never shown at all, he might be left in the lurch and may not even know that some other options exist. So we make sure we sort the proposals according to the relevance in the current context, but dont outrightly reject other proposals that may/may not be relevant (In reply to comment #1) > With this above example, content assist gives you the (public) constructors for > ByteArrayInputStream at the top of the list, and some other constructors after > that. > Do you mean that you dont see constructor for ByteArrayInputStream at > all? Yes, I see the constructor for ByteArrayInputStream first and then *lots* of other suggestions. > Or are you saying that we should only show constructors for > ByteArrayInputStream and its subclasses and not show the other results? Yes, I am saying exactly this. > Extra proposals in content assist are usually not evil - they give the user > some flexibility and incase he realises that he did not want to create a > ByteArrayInputStream object, but say some ByteArrayInputStream2 object, he can > still chose the constructor for that and go back and make a change to the > declared type. If the proposal was never shown at all, he might be left in the > lurch and may not even know that some other options exist. So we make sure we > sort the proposals according to the relevance in the current context, but dont > outrightly reject other proposals that may/may not be relevant The problem is that the current behaviour is suggesting completions which are nearly *always* incorrect in the current context. Why are we wasting time generating huge lists of constructors that cannot be used? I believe content assist should generally only be suggesting valid Java code otherwise it is more of a hindrance than a help. Also the classes which generates the list of proposals sometimes a take a lot of time to complete so the user waits only to find that nearly all of the suggestions are inappropriate anyway! This I believe is more damaging to the user and the *expected* behaviour of this feature than the current behaviour of being able to select *any* constructor (relevant or not). If we wanted to keep the current behaviour we could cycle to *all* choices by pressing "Ctrl+Space" again but the first list presented when the user activates content assist should show only the relevant choices. I believe this would *vastly* improve the usability of content assist. (In reply to comment #2) > (In reply to comment #1) > The problem is that the current behaviour is suggesting completions which are > nearly *always* incorrect in the current context. Why are we wasting time > generating huge lists of constructors that cannot be used? I believe content > assist should generally only be suggesting valid Java code otherwise it is more > of a hindrance than a help. Need to double check, but IIRC, code assist by design is not aware of type hierarchies. When the type names are retrieved from search indexes we have no idea which types could be subtypes of BAIS. (In reply to comment #3) > [..] > Need to double check, but IIRC, code assist by design is not aware of > type hierarchies. When the type names are retrieved from search indexes > we have no idea which types could be subtypes of BAIS. We can evaluate and check if each retrieved type is a subtype for, say BAIS in this case, but that would slow down code asssist even more - and that would completely undermine the intention of doing that in the first place i.e. to spend less time and generate a smaller list. So, basically I think adding further evaluations to code assist will only worsen the case at hand. Maybe we can think of presenting a truncated list to the user at the first go, say, 10 suggestions and pressing ctrl+space again would show the entire list. Doing this, though, will entirely be a UI change and will *not* lead to any performance improvement. Gary, I can tell you something that can ateast help you use code assist more efficiently. In this case, if you just type new BAIS and then press ctrl+space, u'll see just two constructors for the desired type ByteArrayInputStream, since code assist recognises camel casing. This is also almost instantaneous. (In reply to comment #4) > (In reply to comment #3) > > [..] > > Need to double check, but IIRC, code assist by design is not aware of > > type hierarchies. When the type names are retrieved from search indexes > > we have no idea which types could be subtypes of BAIS. > > We can evaluate and check if each retrieved type is a subtype for, say BAIS in > this case, but that would slow down code asssist even more - and that would > completely undermine the intention of doing that in the first place i.e. to > spend less time and generate a smaller list. I see your point. With this in mind I think that content assist *needs* to have access to the compiler/type hierarchy mechanism to make sensible user suggestions. Asking for the type hierarchy of even something like "java.util.List" is actually quite quick (quicker than generating a huge list of alphabetic constructors it seems). So my proposal for content assist looks like this : 1. When the user 1st hits Ctrl+Space we ask for the type hierarchy of the type on the LHS and display all public constructors for it and all subclasses. If the type has not been imported yet we should still do the same thing and then automatically import if the user accepts the suggested code completion. 2. When the user hits Ctrl+Space again we are back to the current behaviour. I understand that this might not be trivial to change (I intend to start digging in the source code tonight :-) but I believe the time & effort in implementation is well worth the return of a much enhanced content assist. > So, basically I think adding further evaluations to code assist will only > worsen the case at hand. Maybe we can think of presenting a truncated list to > the user at the first go, say, 10 suggestions and pressing ctrl+space again > would show the entire list. Doing this, though, will entirely be a UI change > and will *not* lead to any performance improvement. > > Gary, I can tell you something that can ateast help you use code assist more > efficiently. In this case, if you just type new BAIS and then press ctrl+space, > u'll see just two constructors for the desired type ByteArrayInputStream, since > code assist recognises camel casing. This is also almost instantaneous. Thanks for the new shortcut :-) (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > [..] > > > Need to double check, but IIRC, code assist by design is not aware of > > > type hierarchies. When the type names are retrieved from search indexes > > > we have no idea which types could be subtypes of BAIS. > > > > We can evaluate and check if each retrieved type is a subtype for, say BAIS in > > this case, but that would slow down code asssist even more - and that would > > completely undermine the intention of doing that in the first place i.e. to > > spend less time and generate a smaller list. > > I see your point. With this in mind I think that content assist *needs* to have > access to the compiler/type hierarchy mechanism to make sensible user > suggestions. > > Asking for the type hierarchy of even something like "java.util.List" is > actually quite quick (quicker than generating a huge list of alphabetic > constructors it seems). > > So my proposal for content assist looks like this : > > 1. When the user 1st hits Ctrl+Space we ask for the type hierarchy of the type > on the LHS and display all public constructors for it and all subclasses. If > the type has not been imported yet we should still do the same thing and then > automatically import if the user accepts the suggested code completion. > > 2. When the user hits Ctrl+Space again we are back to the current behaviour. > > I understand that this might not be trivial to change (I intend to start > digging in the source code tonight :-) but I believe the time & effort in > implementation is well worth the return of a much enhanced content assist. > > > So, basically I think adding further evaluations to code assist will only > > worsen the case at hand. Maybe we can think of presenting a truncated list to > > the user at the first go, say, 10 suggestions and pressing ctrl+space again > > would show the entire list. Doing this, though, will entirely be a UI change > > and will *not* lead to any performance improvement. > > > > Gary, I can tell you something that can ateast help you use code assist more > > efficiently. In this case, if you just type new BAIS and then press ctrl+space, > > u'll see just two constructors for the desired type ByteArrayInputStream, since > > code assist recognises camel casing. This is also almost instantaneous. > > Thanks for the new shortcut :-) Guys, where are we with this? Are you looking into it? (In reply to comment #6) >[..] > Guys, where are we with this? Are you looking into it? I will get back to this as soon as possible, once the priority items are taken care of. Thanks This might be works as designed. One may want to create byte stream like the following: ByteArrayInputStream input = new MyStreamFactory().createStream(byteArray) 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. |
Build Identifier: M20100909-0800 The description refers to the code below. //============================================================================ import java.io.ByteArrayInputStream; public class TestMain { public static void main(String[] args) { ByteArrayInputStream input = new B* } } * = The location of the cursor //============================================================================ If I press Ctrl+Space at this point in the Java editor content assist shows me a very large list of constructors to complete this statement. The problem is that almost all of them are invalid. I would expect content assist to show *only* the public constructors for ByteArrayInputStream and it's subclasses because the type of the parameter we are trying to assign is known and in scope. Even if the parameter type wasn't currently in scope I would expect content assist to attempt to work it out and then present valid suggestions based upon it. Reproducible: Always