Scott brought up an interesting idea for how completion lists could work:
"ArrayList someList = new
I would expect "ArrayList" to pop-up in a list, already highlighted, and any other known sub/supertypes of ArrayList to be close to the highlighted "ArrayList" option, instead of having to scroll through the entire list or type the first N keys to find my class. I'd expect a little more intelligence there."
I must say that:
One thing we've discussed is the new VB 2005 model. In that model you actually get a tabbed completion list. One tab shows all valid intellisense members and one tab shows all common members. A place where this would be useful would be the following:
You might expect that we just show Types that derive from System.Exception, however that wouldn't be correct. For example you could type
throw new MyClass().GetSharedException()
While unlikely, it could happen, and we don't want to aggravate power users who are typing correct C#. However, you could imagine that in the 'all' tab we would place newable types, and in the 'common' tab we would place things that derive from System.Exception. Another option that we've been debating is to throw away the concept of a completion 'List'. Scott's problem above is that we are taking a rich tree/graph of information and we're dumbly reducing it to a list. Scott mentions intelligent reduction to a list, however, what about intelligent reduction to a tree?
What if we could select ArrayList in the list with a + next to the name. If you then expanded that you'd see the types that directly derived from ArrayList with +'s next to them as well
The issue with all UI presentation is that we provide useful information while not showing obtrusive unhelpful UI. So one could easily argue that the +'s would be obtrusive UI. It might take far too much effort to think about that and expand it. In fact, one could argue that things like completion lists should work in a google-like manner. In an ideal world the item you wanted would be the one that was preselected. Of course, that won't happen until we ship a version of VS that comes with a electrodes. (also, if we could preselect the correct item, then we really wouldn't need to pop up the list). So, like google, we should try to get the best item first and then have the next most likely following afterwards. That way with a single glance of 10 items you have a 90+% chance of getting what you want. The problem then is: what if we don't show you the item you need. What if it's in that 10% that we screw up. The benefit of sorting the list alphabetically is that one could scan through the list with some idea where the item might be. Without sorting, it could be incredibly confusing for the user.
Another idea is if we were to group items. For example, in a completion list that comes up to show you the members of an object, we could group by fields/methods/properties/accessibility/etc. We could also trim down the list as you type. What do you think of those ideas? Do you have any more that you would be interested in?