New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Mode format #5
Comments
If I understand it correctly this is about Language Support? How much overlap is there with #10 ? If a new format is wished for, I would like to recommend to start with looking at the format that TextMate is using, as far as I understand it, Sublime is using that same or a very similar format and lately VS-Code seems to also support it. A link that at least seams to partially describe the format: https://ilkinulas.github.io/programming/2016/02/05/sublime-text-syntax-highlighting.html |
It's probably worth doing a safari around to see how far apart everyones implementation is these days. Note that sublime itself moved on to http://www.sublimetext.com/docs/3/syntax.html As far how much overlap there is with #10: I don't think much as even with Language Server Protocol support we will want to keep the local mode around as an option at least. |
Here is the old TextMate definition VSCode seems to compile something from yaml (maybe what sublime is using?) None of these implementers seem to link to a spec of their formats anywhere. VSCode has this script which you could argue is some sort of specification. :/ Not pretty. But there are at least a lot of .tmlanguage files for various languages around. One principal problem I remember from digging at these files last, is that for languages like python, stuff like this is not (or not efficiently) parseable: def thisFunction():
return """
has a string that is not indented
""" Folding fails for this, because it does not detect that the function does not end on the second line of the string. Well at least that was a problem once. |
LSP currently does not support this: Proposal of the semantic highlighting protocol extension #367. |
Want to tackle this rather sooner than later. The current mode file format is to annoying to go back and forth because of the XML escaping and a lot of the built in modes get old in the teeth or need more modern replacements, additions. Since no cool community has been found to address this, it might also be prudent to think about basic ingestion of other existing highlighting formats (e.g. from textmate, sublime, et. al) to at least get the ball rolling and expanding again. Having a flexibile highlighter and mode format is a great benefit to support a breadth of files, which SubEthaEdit currently leaves on the table. I'd also like to actually extract and isolate the highlighting code during that process more so it could be adopted by other parties of interest. |
So my first order of business would be to just explore a |
Also this seems to be some specification of the TextMate format: https://macromates.com/manual/en/language_grammars |
I would really like to see the ability to use TextMate or VSCode language bundles as that would open up a lot of language definitions that are out there already. |
While it served us well in the past, creating modes isn't as easy and straight forward as it could be. We should reconsider updating the mode bundle format to improve on some of it's clumsier aspects:
Along those lines we should also think about making the mode states more semantical to improve reuse. While importing of modes is a great feature to have full language capabilities in all languages that embed other languages, there would be great potential to have great semantic entities for e.g. strings and number representations that can be mixed and matched to optimally and correctly represent them for the current mode.
The text was updated successfully, but these errors were encountered: