Currently if one CodeLens provider is slow, it prevents other CodeLenses from appearing (or if they appear from the cache, from being clickable).

This means if one kind of CodeLens might be slow to compute, you need to pick between:

1. Returning no CodeLens and triggering onDidChangeCodeLenses when the data is available
2. Causing all other CodeLenses to appear slow/not interactable for the time it takes to get the data

The problem with (1) is that it causes the editor to bounce around. If a provider says it has 0 CodeLenses just because it can't return quickly, the cached CodeLenses/spaces will be removed, and then they will be added back when the CodeLenses are available. The problem with (2) is that it increases the chances that the user wants to interact with a CodeLens but can't.

It would be better if each provider was handled individually so a fast provider can have its CodeLens shown (and interactable) even if all others aren't.

I'm aware of resolve, but it doesn't help if just computing the locations for CodeLens relies on data from a language server that is being recomputed because the document was modified. I have a timeout on waiting for this data that was initially set to 5s, however after adding new CodeLenses I saw they would sometimes take 5s to appear. If I lower the timeout on the "potentially slow" CodeLens, then it increases the chances of the CodeLenses disappearing and re-appearing as the user is typing. There is no good value to pick, it's always a trade-off between (1) and (2) above with the current design.