Add weight/priority to code lens providers

[eamodio]

• VSCode Version: Code - Insiders 1.13.0-insider (c8123b0, 2017-06-06T21:31:11.642Z)
• OS Version: Windows_NT ia32 10.0.16199

---

Maybe I'm imagining it (or maybe it was only for code lens from the same provider), but I thought code lens where show in order based on their range.

I quickly hacked vscode to display the range at the end of the code lens -- and you can see here that the implementation and references code lens have a cols that are before the GitLens ones.

In the latest (beta) of GitLens I was trying to force my code lens to always be at the end of the line (because I would MUCH rather have implementations and references at the start), but even with adding the code lens range at the end of the line, it doesn't seem to help the ordering. I'm really hoping to be able to provide at least some level of consistency to the positioning of the code lens if at all possible.

Did this change? Is there any way to get this behavior?

//cc @jrieken

[jrieken]

The sort-order goes by line, provider-rank, and then column: https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/codelens/common/codelens.ts#L39. We do that to keep lenses from different provider stable. @eamodio Leaves the question if all those lenses are from the same provider or not?

[eamodio]

@jrieken These are of different providers -- the first 2 are GitLens the others are typescript. So I guess the provider-rank comes from something like the order loaded? Or is that something controllable -- like can I make GitLens very low (i.e. last)?

[jrieken]

So I guess the provider-rank comes from something like the order loaded?

Exactly, the order in which they register. Extensions cannot influence the order, unsure if they should

[eamodio]

Yeah -- its tricky, but in some ways it isn't too different than allowing extensions control over the order (priority) of their items on the the status bar. Its just that the way it is now, is stable for a single language, but cross-languages it can be very different (each stable on their own of course).

So for example, if I open a typescript file, depending on load times, sometimes the references/implementations will "win" (i.e. be listed first) and sometimes GitLens wins (what I don't want). But then if I open a C# file (in the same workspace), the references may or may not win -- and can show in a different order than the other. And to a user, I don't necessarily get that those reference codelens are completely different things -- they look and feel the same to me.

But even without the cross-file type deal, just having GitLens win sometimes and be at the front, is pretty annoying when references/implementation (and probably many others) are pushed over because of it. So it would be great if there was some way, I could have Gitlens say it was of "low priority" or something

[jrieken]

Yeah, can be compare to status bar items which justifies having a prio but also to code-actions which don't have that. Generally because we don't want extensions start fighting over the order of things.. Needs some thinking

[eamodio]

Agreed. Just my 2c, since code-actions are on-demand (rather than always visible) I would say they are less important to control the ordering. Where as the status bar and code lens are always (well not always) there in your face.

[eamodio]

September milestone? ;)

[jrieken]

:-) unfortunately not... Tho, I could review a PR

[eamodio]

OK -- I'll see what I can whip up ;)