Lsp: Is the "syntaxes" key really needed?

Created on 27 Mar 2019  路  18Comments  路  Source: sublimelsp/LSP

It seems to me it is only necessary to know the scope of the view (e.g. source.js) and not the syntax (e.g. Packages/Javascript/Javascript.sublime-syntax). The syntax file is a particular provider for such a scope.

If we were to abandon the syntaxes key, changes like https://github.com/tomv564/LSP/pull/539 would be unnecessary.

This question is partially inspired by this forum post: https://forum.sublimetext.com/t/react-syntax-highlighting/42776

discussion

Most helpful comment

I disagree.

It's needed in case where two servers handle same language:

"ts-ls":
{
    "enabled": true,
    "command":
    [
        "lsp-tsserver"
    ],
    "languageId": "javascript",
    "scopes":
    [
        "source.js",
        "source.ts",
        "source.tsx"
    ],
    "syntaxes":
    [
        "Packages/JavaScript/JavaScript.sublime-syntax",
        "Packages/TypeScript Syntax/TypeScript.tmLanguage",
    ]
},
"vue-ls":
{
    "enabled": true,
    "command":
    [
        "vls"
    ],
    "languageId": "vue",
    "scopes":
    [
        "text.html.vue"
    ],
    "syntaxes":
    [
        "Packages/Vue Syntax Highlight/Vue Component.sublime-syntax"
    ]
}

The vue-ls server handles single file component files (vue files) which handles both html and javascript (source.js context). If ts-ls would be allowed to run on such files too (it would without syntax specified) then those would be checked twice (with potentially conflicting results).

JS blocks in vue files have these scopes text.html.vue source.js.embedded.html source.js, so if it would be possible to exclude text.html.vue scope then it should also work in theory. Is it possible right now?

All 18 comments

Yes, the syntaxes config key is unnecessary.

I was working on this. You can try it here:
https://github.com/predragnikolic/LSP/tree/remove-syntaxes-from-config

I can do a PR, but I know I broke some tests and I don't know if I broke something else :D

I disagree.

It's needed in case where two servers handle same language:

"ts-ls":
{
    "enabled": true,
    "command":
    [
        "lsp-tsserver"
    ],
    "languageId": "javascript",
    "scopes":
    [
        "source.js",
        "source.ts",
        "source.tsx"
    ],
    "syntaxes":
    [
        "Packages/JavaScript/JavaScript.sublime-syntax",
        "Packages/TypeScript Syntax/TypeScript.tmLanguage",
    ]
},
"vue-ls":
{
    "enabled": true,
    "command":
    [
        "vls"
    ],
    "languageId": "vue",
    "scopes":
    [
        "text.html.vue"
    ],
    "syntaxes":
    [
        "Packages/Vue Syntax Highlight/Vue Component.sublime-syntax"
    ]
}

The vue-ls server handles single file component files (vue files) which handles both html and javascript (source.js context). If ts-ls would be allowed to run on such files too (it would without syntax specified) then those would be checked twice (with potentially conflicting results).

JS blocks in vue files have these scopes text.html.vue source.js.embedded.html source.js, so if it would be possible to exclude text.html.vue scope then it should also work in theory. Is it possible right now?

I have to disagree with myself and agree with Rafal concerns.

It would be great if we could throw away the syntaxes config setting.
But, I don't know how to solve the example above with two servers conflicting.

I tried to use the view.score_selector to try to give priority to the "right" server, but I didn't succeed.

That's a great functional explanation for the need for syntaxes - if someone wanted to look into the scopes api where we can identify source.js as a secondary scope then that might provide a way out.

A nice optimisation with ViewEventListeners is that we can enable the LSP logic once for the lifetime of the view if the syntax matches - the same cannot be done by scope (as far as I know)

I don't want to end the discussion here but will close the issue for now as it's not an urgent user-impacting concern.

I don't quite understand the example given @rchl, could you elaborate a bit further on the use case?

Wouldn't a scope of source.js - text.html.vue suffice to run the vue language server on text.html.vue and not the typescript language server?

https://www.sublimetext.com/docs/3/selectors.html

Well, my last suggestion is possibly bogus, but I do think we can accomplish what you want with logical operators.

The more I look at the Vue and Javascript example the more I don't understand it. Let me try to explain your problem and please correct me if I make any mistakes.

  • When we open a .vue file, we want a vls session
  • When we open a .js or .ts file, we want a ts-ls session
  • ???
  • When we open a .vue file, we want a vls session
  • When we open a .js or .ts file, we want a ts-ls session
  • ???

Yes, that's what we want.
If we had only scopes to decide that, how would you prevent ts-ls from initializing when opening .vue file? We only know the scope under the cursor right?

Or in other words, when would language server initialize when we would only decide that based on the scope? Would it only happen when I move the cursor inside the

Every .sublime-syntax file has a top-level scope key that describes its top-level scope.

We can thus simplify our config_supports_syntax by opening the given syntax file, and reading the top-level scope property, then comparing that to the scopes list in the config.

sublime_lib already has exactly this functionality.

This would be sufficient for your situation:

When opening a Vue file, we invoke

config_supports_syntax(config, "Packages/Vue Syntax Highlight/Vue Component.sublime-syntax")

-> open that syntax file
-> read `scope` top-level key (get text.html.vue)
-> match against text.html.vue from the config

When opening a Javascript file, we invoke

config_supports_syntax(config, "Packages/JavaScript/JavaScript.sublime-syntax")
OR
config_supports_syntax(config, "Packages/Babel/JavaScript (Babel).sublime-syntax")

-> open that syntax file
-> read `scope` top-level key (get source.js)
-> match against source.js from the config

Then I suppose it might work. :)
We can try it out.

My LSP settings rely on syntaxes much. I am interested in trying this change as well.

We still want that, I believe (per https://github.com/sublimelsp/LSP/pull/825#issuecomment-580871289 comment)

For sure! Just have patience :)

Fixed by #931.

syntaxes is replaced by document_selector.
scopes is replaced by feature_selector.

There is no feature_selector in the docs btw.

Thanks for letting me know, I'll add docs :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

predragnikolic picture predragnikolic  路  7Comments

chenglou picture chenglou  路  4Comments

jfcherng picture jfcherng  路  4Comments

lsmenicucci picture lsmenicucci  路  3Comments

gerardroche picture gerardroche  路  3Comments