Allow language extensions to provide status information

Many language extensions add status bar entries for various information tidbits, like version, language server status, project etc. There is many inconsistencies for how this happens like alignment isn't always in sync with the language name or visibility isn't in sync with the active editor.

We should help extensions do a better job by adding a dedicated "language status" API, some kind of LanguageStatusProvider which we query whenever the editor changes. In its simplest form language status can be text, detail (supporting codicons and md), and severity.

API sketch

enum LanguageStatusSeverity {
    Information,
    Warning,
    Error
}

declare class LanguageStatus {

    text: string;
    detail: string | MarkdownString;
    severity: LanguageStatusSeverity;

    constructor(text: string);
}

interface LanguageStatusProvider {
    provideLanguageStatus(): ProviderResult<LanguageStatus>;
}

declare namespace languages {
    export function registerLanguageStatusProvider(selector: DocumentSelector, provider: LanguageStatusProvider): Disposable;
}

Matt Bierner (@mjbvz)

fyi Matt Bierner (@mjbvz)

Good stuff.
Not sure about text and detail, I would suggest to go with just message: string | MarkdownString.
I imagine this to be shown in a hover over the language mode status bar entry (e.g. 'JSON'). As there can potentially be multiple providers active for a given document, the hover would combine all the messages by concatenating them.

Looks promising. Here's the information we'd potentially like to show for JS/TS:

The current TS version (plus a way to switch versions)
The state of TS server.
- Are we spinning up a full server? Right now we show initializing JS/TS language features progress in the status bar for this
- Are we in partial only mode. If this is the case, we'd like to tell users that operations such as workspace symbol search may be incomplete
Potentially if logging is enabled and a quick way to jump to the log file

Additionally, it would be nice if we could customize the displayed information per-file instead of showing the same status for all files of given language. For JS/TS, this could be:

The tsconfig/jsconfig that the current file belongs to (and a way to quickly go to that config file)

If multiple extensions can contribute to the language status, it may also make sense to move some ESLint information into the language status

So my high level questions:

Should this API be per-file or per-language?
- The current API uses a pull model but if we instead had a push model, we could leave this decision up to extensions like we do for status bar items
Should Language Status be a single item or an array of items?
Can multiple extensions contribute to a language status?

Dirk Bäumer (@dbaeumer)

//CC Dirk Bäumer (@dbaeumer)

first cut for language status API proposal, #129037

Extensions can always take advantage of the existing vscode API to add additional status bar entries, with command handler, icons, colors, menus etc.
That's why I suggest that for the beginning we keep it simple and introduce a LanguageStatusProvider returning a MarkdownString that we can show as hover over the language selector. Thats something we currently can't do through API. Such API is also straightforward to adopt in LSP.

Keep it proposed for a while and I can adopt it in HTML, CSS and JSON to gain some UX experience

simple and introduce a LanguageStatusProvider returning a MarkdownString.

I think we need more than just a message because we need to show some kind of anchor in the status bar. I initially tried to hijack the language item for that but it has the "Change Language" message and command.

some more API doc, #129037

finalize `LanguageStatusItem` API, #129037

To verify simply make sure that createLanguageStatusItem is in vscode.d.ts

Johannes Rieken (@jrieken)

hi Johannes Rieken (@jrieken), I'm trying to adopt this API in Java language support and it works well 👍. And I just find if we pin an item and we mark it busy, the spinning icon will appear in both language status item (the left one) and pinned item (the right one).

IMO it's a little duplicated and it's better to show the busy icon only in the language status item (the left one) to help users focus on the item. Does it make sense?

I agree. Can you please file a separate bug for that. Thanks

Johannes Rieken (@jrieken)

Johannes Rieken (@jrieken) thanks for the swift reply! issue created here: #145115

Shi Chen (@CsCherrYY)

Hey Shi Chen (@CsCherrYY) are you saying the left one isn't pinned? How did you get it to show up like that?

Here it is unpinned for us (it only shows up under the {} icon, and unpinned is the default, which is annoying our users):

And after manually pinning it:

Andy Jordan (@andschwa)

Andy Jordan (@andschwa) The default in my case seems to be pinned. So in my screenshot, the default is only to show the left one, but no the right one.

But if you choose to unpin this item, the right one appears. It works when we just change the severity, text, etc. , but if we mark it busy, duplicate busy icons appear.

Here is a suggestion about the visibility, sorry for disturbing. 🙂

We find abnormal severity (error or warning) for unpinned status (which is the default behavior) is not easy to find, compared to the pinned item.

pinned error:

unpinned error:

Users will find the status easier for the pinned item than the unpinned item, since the background is different. Can we consider changing the background color of the pinned item as well? (or another way to help users find this status)

Navigation Menu

Repository navigation

Allow language extensions to provide status information #129037

120 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow language extensions to provide status information #129037

Description

Activity

jrieken commented on Jul 20, 2021

jrieken commented on Jul 20, 2021

aeschli commented on Jul 20, 2021

mjbvz commented on Jul 20, 2021

egamma commented on Jul 21, 2021

aeschli commented on Jul 21, 2021

jrieken commented on Jul 21, 2021

120 remaining items

jrieken commented on Feb 21, 2022

CsCherrYY commented on Mar 15, 2022

jrieken commented on Mar 15, 2022

CsCherrYY commented on Mar 15, 2022

andyleejordan commented on Mar 15, 2022

CsCherrYY commented on Mar 16, 2022

CsCherrYY commented on Mar 24, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions