IntelliSense rules for “get best match” during mem

问题:

First of all, I finally made this a wiki, but I believe a "simple," straightforward answer is highly desirable, especially since the result would define a unified IDE behavior for everyone. More on the simple later.

In the past, I've blogged about what it means to have a well-behaved member selection drop down. If you haven't read it, do so now. :)

Visual Studio 2010 adds new features to the IntelliSense selection process that makes things ... not so easy. I believe there's great power we can harness from these features, but without a clean set of governing rules it's going to be very difficult.

Before you answer, remember this: The rules should allow someone "in tune" with the system to take advantage of the IntelliSense power with fewer keystrokes and less time than other solutions provide. This is not just about what you're used to - If you use a system as long and frequently as I do, relearning the patterns is trivial next to the time it saves to have a great algorithm behind it.

Here are the controllable axes:

• Filtering: A "full" list contains every identifier or keyword allowed at the current location, without regard for the partially typed text the cursor is within.
• Sorting: We (at least Visual Studio users) are used to the member selection drop down being sorted in alphabetical order. Other possibilities are partial sorting by some notion "relevance," etc.
• Selection: Based on the currently typed text, we have the ability to select one item as the "best match." Selection states are:
  • No item selected
  • Passive selection: one item outlined, but pressing ., <space> or similar won't fill it in without using an arrow key to make it:
  • Active selection: one item selected, and unless Esc or an arrow key is pressed, a . or <space>, etc will auto-complete the item.

My previous set of rules restricted the manipulation to the selection axis. They took into account:

• Characters typed as matched against list items with a StartsWith operation (prefix matching), with variants for whether the match was case-sensitive.
• Previous completions that started with the same set of characters.

The following are additionally available and potentially useful, but not all have to be used:

• CamelCase matches or underscore_separation ("us"): Long, expressive identifiers? Not a problem.
• Substring matches: long prefixes hindering your selection speed? Not a problem.
• Information available in the summary text, where available: I lean against this but I must admit it's come in handy in the Firefox address bar, so you never know.

The rules you write should address the axes (in bold above) in order. In my previous posts on the subject, the rules were very simple, but the additional considerations will likely make this a bit more complicated.

1. Filtering
2. Sorting
3. Selection

回答1:

Just one addition or remark ...

IntelliSense should adapt to the context. In the case of Visual Studio, places where only subtypes of a specific type or interface may be used, the dropdown list should filter by these.

IList list = new (Drop down all the types implementing IList) - not all possible types!