Open DanielRosenwasser opened 2 months ago
Moving this out of the issue body, since this is more of my own suggestion than a spec.
A good experience here may need some clever thinking. Some parts of quick info which a user may want to expand may be totally unrelated to what actually gets expanded out.
One possible direction here is to expand in a breadth-first way instead of depth-first. For example, if a user sees the following type:
/* Verbosity 0 */
{
foo: Foo,
bar: Bar,
baz: Baz,
}
expanding on a depth-first basis might pop everything out in the following way
/* Verbosity 0 */
{
foo: Foo,
bar: Bar,
baz: Baz,
}
/* Verbosity 1 */
{
foo: {
fooProp: string
},
bar: {
barProp: string
},
baz {
bazProp: string
},
}
whereas allowing expansion on a breadth-first level might be a little less daunting, albeit more tedious:
/* Verbosity 0 */
{
foo: Foo,
bar: Bar,
baz: Baz,
}
/* Verbosity 1 */
{
foo: {
fooProp: string
},
bar: Bar,
baz: Baz,
}
/* Verbosity 2 */
{
foo: {
fooProp: string
},
bar: {
barProp: string
},
baz: Baz,
}
/* Verbosity 3 */
{
foo: {
fooProp: string
},
bar: {
barProp: string
},
baz {
bazProp: string
},
}
Ref #31384 which previously experimented with instrumenting diagnostic message construction to allow expandable spans like this.
Related on Stack Overflow:
There is a lot of interest and discussion in #38040 and #56010 when it comes to showing/hiding details of a quick info request. In https://github.com/microsoft/vscode/issues/195394, we have a proposed client/editor API to serve up such an experience, and we'd like to provide it.
There are some questions that still need to be answered and prototyped. For example, what precisely should be expanded? In some cases, a type reference can be expanded into its structural form. In others, an elision (
...
) can possibly be shown. Whether this is always desirable is questionable.