Repository navigation
Add config to set syntax for dynamic text document content - #2962
Conversation
β Deploy Preview for sublime-lsp ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| "jetls-macro-expansion": "Julia.sublime-syntax", | ||
| "jetls-type-annotation": "Julia.sublime-syntax" |
There was a problem hiding this comment.
Found few places that use window.new_files() and those pass syntax name in a format Packages/PackageName/SyntaxName.sublime.syntax.
- https://github.com/sublimelsp/LSP-volar/blob/32f917a99031b116daf7c82b8d3d355faa80b2c7/volar_virtual_file_hierarchy.py#L212-L214
- https://github.com/sublimelsp/LSP-jdtls/blob/2e675dc8a3a9442171777323d0a42a2e5ee24475/modules/test_extension_server.py#L362-L363
Also we could support passing base scope here which would be a bit more future proof.
There was a problem hiding this comment.
Yeah, thereβs something like sublime.syntax_for_scope I believe.
There was a problem hiding this comment.
Found few places that use
window.new_files()and those pass syntax name in a formatPackages/PackageName/SyntaxName.sublime.syntax.
This is just an example, and users can use the full path if they prefer. I prefer the simple form here because that is less text to read and smaller chance to introduce typos in case someone wants to type that manually.
Also we could support passing base scope here which would be a bit more future proof.
I've thought about this, and I think specifying the syntax directly could be more flexible, because a helper package might want to contribute a custom syntax for certain URI schemes. Similar to what LSP-pyright does for the Markdown fenced code blocks. Technically you could also use a different syntax scope in that case, so specifying syntax or scope should be kind of indifferent, but IMO syntax is more explicit and that is what Window.new_file also takes as the argument. Actually you can even put "jetls-macro-expansion": "scope:source.julia" into this mapping, but in that case the syntax label in the bottom-right corner is bugged: sublimehq/sublime_text#4449
In which way do you think scope would be more future proof?
There was a problem hiding this comment.
This is just an example, and users can use the full path if they prefer. I prefer the simple form here because that is less text to read and smaller chance to introduce typos in case someone wants to type that manually.
I just thought that using just the file name is invalid and won't work. If it works then it's fine as is.
In which way do you think scope would be more future proof?
Was thinking that it would be resilient to syntax path changing if it refers to some third party syntax that maybe later becomes included in ST or changes owner. But maybe that's a rare case.
This allows to declare the syntax for buffers with custom URI schemes that are used by the
workspace/textDocumentContentrequest.Not sure if "syntax_map" is the most descriptive name, but it's somewhat consistent with the existing "markdown_language_map" and I couldn't think of any better name.
Confirmed to work with the JETLS server, which uses custom URI schemes when running certain code actions.