Async functions in documentSymbols and completion

[superbobry]

textDocument/semanticTokens has an async modifier which can be used to distinguish def f(): ... from async def f(): .... How hard would it be to support async functions in textDocument/documentSymbols and textDocument/completion as well?

[rcjsuen]

Your goal for this would be so that the client adds some decoration to the function's icon to indicate that it is async to inform the user visually?

[superbobry]

Yes, that is indeed the intent. I want async functions to be visually distinct from the non-async ones.

[rcjsuen]

Sounds to me like you probably want to introduce new enums for CompletionItemTag and SymbolTag. Alternatively, one could argue for new enums for CompletionItemKind and SymbolKind.

[superbobry]

That sounds right. How should I go about doing this? Would a PR work or do such changes need to be approved in principle first?

[dbaeumer]

Since async is a modifier not a kind I would argue that they should be encoded as tags.

Before something goes into the specification we need an implementation in clients first (one that advertises the tag as a client capability and implements a different rendering in the UI for the tag)

[superbobry]

Yeah, I agree that tags are the way to go here.

Can you link me to the repo with the client, please?

[rcjsuen]

Can you link me to the repo with the client, please?

You can pick whichever LSP client you want technically speaking. I presume you are developing a language server right now and testing it with some client so you could contribute to that client (under the assumption that whatever client you are using is open source as it might be difficult for you to suggest a change to the maintainers otherwise).