Misleading intellisense when assigning in-line functions in Visual Studio

[NoelAbrahams]

Hi,

VS: 2015 CTP 5
TS: 1.4

In the snapshot below, we are at the point of assigning an inline function to property foo:

The intention is to write something like

x.foo = bar => bar.toString();

Clearly, the provided completion list is not very helpful here.

Furthermore, when the letter b is typed intellisense shows an already _selected_ item in the list of completions. By this I mean the item blur is highlighted with a background colour. This provides a misleading impression that an exact match has been identified by the intellisense engine, providing a (false) incentive for the user to hit tab in order to complete the term.

I believe the more correct behaviour here is to

• not show intellisense at all unless a type compatible with x.foo exists, or

• only show an outline, similar to the one below:

  

[DanielRosenwasser]

The first part of this (e.g. completion when trying to type a lambda and similar constructs) seems like a duplicate of #1629, which we fixed in #1767.

---

not show intellisense at all unless a type compatible with x.foo exists, or

This is hard. Are you saying that we shouldn't show num in the following case?

var str: string;
var num = 123;
str = /*completion list selected here*/

Because you can easily end up typing something like

var str: string;
var num = 123;
str = num + "hello!";

which is valid.

Furthermore, if you have

interface Bar {
    x: number;
}

interface Foo {
    bar: Bar;
}

declare function fizzle(): Foo;

var bar: Bar = /*completion list here*/

Should we not show fizzle in a completion list? Because you can call fizzle() and grab the bar property.

Type-directed completion is in some sense ideal, but I have a hunch that there are only marginal gains for a lot of complexity.

---

As for your UI bug, I'd try opening up a separate issue because it is already conflated with the other issues you've reported. For the record, I'm not sure if we actually have control over this sort of thing. @CyrusNajmabadi might be able to weigh in on it.

[NoelAbrahams]

There are places where we offer completion lists that we shouldn't, or poor completion lists, which were previously visual distractions but now are significant annoyances in the actual typing experience

That kind of covers what I was trying to get at.

requiring constantly dismissing completion lists via Esc to type what you intended

This is the pain point that I think can be addressed with the UI change (outline vs actual selection).

[NoelAbrahams]

The problem can be mitigated also if we have #494, in other words, by reducing the large number of global objects, most of which we just don't need. The referenced issue seems to be gathering dust - with no milestone specified.

[danquirk]

What are the semantics that determine whether a completion item gets an outline or a different background color?

[CyrusNajmabadi]

@paulvanbrenk Implemented this. The idea is that if this is a place where an arrow function could appear, then we should offer intellisense with the "builder" option set. When this option is set, intellisense knows you might be creating a new name, and it will only give the outlined-select box. You can then type 'tab' to commit that value (if you want it), or hit up/down to go into 'full-select' mode.

[danquirk]

It's not clear to me what a user is supposed to take away from these two highlighting states and how they're supposed to think/act differently based on each.

[NoelAbrahams]

@danquirk,

In the snapshot below

I am forced to hit escape at this point, because if I type a colon then IDBCursorWithValue gets selected. If instead we only showed an outline then the expectation is that typing a colon would not cause the item to be selected.