More specific DocumentSelector/LanguageSelector should have higher precedence

[ris58h]

For now LanguageSelector.score method gives the same score for both { language: 'xml' } and { language: 'xml', pattern: '**/pom.xml' }, but it feels like the second selector should have higher precedence because it's more specific. Even @alexdima assumed the same #129962 (comment)

I'm currently working on an extension for Maven (pom.xml files) and there is a collision with another XML extension because of the issue.

[ris58h]

Current scoring algorithm gives maximum 10 scores for exact equality/match of any filter-property. We could use addition-based algorithm to give more specific selectors higher precedence.

scheme	language	pattern	score (current)	score (addition-based)
undefined	undefined	undefined	0	0 + 0 + 0 = 0
undefined	undefined	matches	10	0 + 0 + 10 = 10
undefined	*	undefined	5	0 + 5 + 0 = 5
undefined	*	matches	10	0 + 5 + 10 = 15
undefined	===	undefined	10	0 + 10 + 0 = 10
undefined	===	matches	10	0 + 10 + 10 = 20
*	undefined	undefined	5	5 + 0 + 0 = 5
*	undefined	matches	10	5 + 0 + 10 = 15
*	*	undefined	5	5 + 5 + 0 = 10
*	*	matches	10	5 + 5 + 10 = 20
*	===	undefined	10	5 + 10 + 0 = 15
*	===	matches	10	5 + 10 + 10 = 25
===	undefined	undefined	10	10 + 0 + 0 = 10
===	undefined	matches	10	10 + 0 + 10 = 20
===	*	undefined	10	10 + 5 + 0 = 15
===	*	matches	10	10 + 5 + 10 = 25
===	===	undefined	10	10 + 10 + 0 = 20
===	===	matches	10	10 + 10 + 10 = 30

If any defined filter-property doesn't equal/match the score is 0.
bold - the scores are different.
Proposed notebookType LanguageSelector's property isn't included in the table but should affect the scoring the same way.

[ris58h]

@jrieken Is the proposed scoring algorithm OK?

[jrieken]

Thanks for raising this issue. I see the thoughts and effort that went in to this. \

Foremost, the changes that are being discussed here are a journey into danger-zone because it will change existing extension behaviour. That doesn't mean nothing can change but very careful consideration needs to take place. Questions are: Does the evaluation of language selector need to change? And iff so, how does it need to change?

I can relate to some of the suggestions but not to all. E.g increasing the score when multiple properties "truly" match sounds reasonable. However, boosting wildcard matches does not sound reasonable - { scheme: '*', language: 'fooLang' } cannot be stronger than just { language: 'fooLang' }

[jrieken]

I guess we should start this by knowing why this needs to change. Apart from "feelings" what are the current shortcomings or issues that could be avoided with the proposed changes?

[ris58h]

Apart from "feelings" what are the current shortcomings or issues that could be avoided with the proposed changes?

Of course feelings shouldn't be the motivation. The motivation is to have a more precise priority mechanism for extensions.

Why do we need this? Because right now when there is a collision between extensions, there is no mechanism to solve it.

It could be done in different ways. For example Intellij IDEA plugins use order field to define the priority. The issue is about the other way - to give more scores to more specific selector.

Why should we go with "score" solution and not with "order" one? There are pros and cons.
Pros:

1. It's expected from the end-user perspective. At least for me and Alex Dima.
2. It's already implemented. We just need to tune it.

Cons:

1. It's a breaking change, but in current implementation the priority mostly depends on the loading order and it seems like it won't affect the existing extensions that much.

However, boosting wildcard matches does not sound reasonable

Thank you for pointing this out. Seems like * should give "at least 5".

scheme	language	pattern	score (current)	score (addition-based)
undefined	undefined	undefined	0	0 + 0 + 0 = 0
undefined	undefined	matches	10	0 + 0 + 10 = 10
undefined	*	undefined	5	max(0 + 0, 5) = 5
undefined	*	matches	10	max(0 + 10, 5) = 10
undefined	===	undefined	10	0 + 10 + 0 = 10
undefined	===	matches	10	0 + 10 + 10 = 20
*	undefined	undefined	5	max(0 + 0, 5) = 5
*	undefined	matches	10	max(0 + 10, 5) = 10
*	*	undefined	5	max(max(0, 5), 5) = 5
*	*	matches	10	max(max(10, 5), 5) = 10
*	===	undefined	10	max(10 + 0, 5) = 10
*	===	matches	10	max(10 + 10, 5) = 20
===	undefined	undefined	10	10 + 0 + 0 = 10
===	undefined	matches	10	10 + 0 + 10 = 20
===	*	undefined	10	max(10 + 0, 5) = 10
===	*	matches	10	max(10 + 10, 5) = 20
===	===	undefined	10	10 + 10 + 0 = 20
===	===	matches	10	10 + 10 + 10 = 30

[jrieken]

Having thought more about this and having discussed this offline with folks I don't believe there is a future for this. The accumulation of filters/restrictions should not yield a higher score. E.g a filter with { scheme: 'file' language: 'fooLang' } shouldn't win over the more generic, yet language specific, filter like { language: 'fooLang' }. The latter is less restricted than the former and shouldn't be penalised for that.

Closing this as out-of-scope