Add providers to tell user their results are incomplete

[mjbvz]

Problem

With #99643, VS Code will be able to provide JS/TS IntelliSense while a project is being loaded in the background. While the project is being loaded however, the IntelliSense results may not be complete.

For example, suggestions will only include suggestions from the current file and go to definition may fail if a symbol is defined in another file.

The only way a user can know that the results are incomplete is by looking for the Initializing JS/TS features entry in the status bar. I believe it would also make sense to indicate that results are incomplete inline where the results are being rendered

Proposal

Allow language feature providers to signal that a result they returned is not complete. This should include a user facing message that explains why the results are incomplete (this message should also potentially allow links so that users can learn more about the issue or take an action to fix the underlying issue)

Off the top of my head, I believe this would make sense for the following providers:

• Completions
• Go to definition
• Go to implementation
• Go to type definition
• Go to declaration
• Find all references
• Workspace symbols
• Hover?

This would allow other language extensions to offer IntelliSense that is progressively enhanced as their project loads. It would also be useful in for serverless scenarios

[jrieken]

We have been there already a few years back and after much thought decided against this. I think adding this to each and every API and then to each and every UI is not helpful and complicates things esp. since the only message that's being transported is: "If this extension wouldn't be soo slow you see useful results here". Back then we we very much in favour of a standardised language status, e.g already today most languages add some kind of version to their name, like TypeScript or Python etc, and most have some kind of custom loading message and we should have good API and UX to unify that. It will be less obtrusive and "the one place" to check for any language status

[mjbvz]

With the work on TypeScript and serverless, we should revisit this. The goal is not to justify why an extension is slow, but to encourage extensions to provide IntelliSense that can be progressively enhanced. The problem that TS faces right now is very similar to the serverless cases we've been discussing

Perhaps adding "incomplete" markers to every provider result is overkill. But at the moment, we only have a convention that a few extensions follow (and I suspect most extensions take an all-or-nothing approach to IntelliSense). We discussed adding a "language status" API for extensions but didn't have enough motivating cases for moving forward with it. Now we have real scenarios that would benefit from a standardized approach to providing progressive enhancement

[jrieken]

Perhaps adding "incomplete" markers to every provider result is overkill.

The challenge is that if we don't put the status into the result it will be very hard for LiveShare to mirror that. Or for the references viewlet to know. Tho we can probably ignore that.

We discussed adding a "language status" API for extensions

I am definitely +1 for a language status API but I am not a fan of putting that into every UI piece. Instead, I'd go for a standard UX that's next to the language name from which you can quickly glance what the current state is.

[mjbvz]

@misolori If you have time this month, let's start exploring how we can improve the UX for TypeScript here and start thinking about how this will relate to our serverless work.

After living with TS's partial semantic support for a few weeks now, I don't think a status bar entry is enough. Several times, I've triggered workspace symbol search and been surprised that the results are not complete. I think the UI should indicate this closer to where the incomplete results are displayed. Once we figure out the UI for this, we can start discussing what the extension Api for it should look like

[jrieken]

IMO, interesting questions are

1. How should an in-widget representation work when having multiple provider? E.g I have an extension which is already providing good results and one which isn't. When I already get what I want, why would I want to see "Still loading XYZ"?
2. How should this work with features that have no "entry UI" like "format on save", "code lens", or "light bulb"?

[jrieken]

Related to this is also how low quality results should be distinguished in environments that cannot provide good results (web) vs local where you (eventually) have good results.