I've been using the dev build for a while now so I could use the .sublime_syntax style files, and I've created a custom JavaScript language definition that highlights ES6 and JSX correctly, which the current bundled JavaScript language definition does not. Is it a goal for the bundled JS definition to include these? I was considering creating a PR into it, but wasn't sure if that is desired.
jontewks
All 14 comments
Others can correct me if I am wrong, but I think the idea here is to improve the existing syntaxes, not necessarily add new ones. So I would think ES6 should be included as it is an update of existing JavaScript syntax, but JSX wouldn't be welcome until Jon decided he wanted to start including JSX support by default rather than using one of the packages in package control.
zchrykng
on 9 Feb 2016
I pretty much believe jsx is a must now, maybe by using and or asking @bathos which is a JavaScript syntax specially designed for ST with the new file and lots of shinny details. The one used in this repository was taken from JavaScript Next (or something like that) which is pretty disappointing.
titoBouzout
on 9 Feb 2016
@jontewks
We are discussing enhancements to the JS syntax at https://github.com/sublimehq/Packages/pull/96.
I don't know enough of how JSX interacts with regular JS syntax to know if it makes more sense to be separate or part of the main JS syntax.
I'd like to move forward with improving the JS syntax since obviously many users utilize it. From a maintenance perspective, smaller tweaks with tests make the process of reviewing and merging easier. The changes at https://github.com/sublimehq/Packages/pull/96 don't seem too drastic, and may be a good base to continue to iterate on.
What are your thoughts?
wbond
on 9 Feb 2016
JSX turned out to be pretty simple to add in my case. Its grammar is small and fortunately introduced no ambiguities -- the "entry-point" token, "<", only begins a JSX expression in contexts where it would not have otherwise been valid as an operator. I don't use JSX myself, but I figured there was no reason not to include support for it since it's widely used and didn't interfere with existing grammar at all.
(Just throwing that out there cause I got an alert for this thread too & I thought it might help answer @wbond re: "I don't know enough of how JSX interacts with regular JS syntax")
bathos
on 9 Feb 2016
Personally I would keep it as a separate syntax just because of things like linters linters that handle only js will flag jsx and linters that handle jsx would ignore errors in js files if someone mistakenly included jsx code.
I will not complain either way though as I am using jsx a lot these days.
zchrykng
on 9 Feb 2016
@wbond thanks for the info. I would love to see incremental updates as small fixes more often as syntax changes. I originally started my own syntax just to stop the dots from highlighting red in the babel syntax, which is now the same in the JS syntax. I'll checkout #96 and see about adding small fixes and tests. I will punt on adding the JSX to that syntax until a decision is made on if it should be separate or not.
jontewks
on 14 Feb 2016
@jontewks you can just modify your color scheme to highlight keyword.operator.accessor (optionally with .js appended) in the same color as your base foreground color, or exclude it from the keyword and keyword.operator matches.
FichteFoll
on 14 Feb 2016
@jontewks FYI I merged #96 in already after adding some tests and fixing some more edge cases.
wbond
on 14 Feb 2016
The built-in JavaScript syntax has gone through almost a complete rewrite at this point, with many tests. I believe at this point it has excellent support for ES6/ES2015. Please do open issues for any problems you find.
I believe that JSX should probably be a different syntax, just from a user perspective. Doing so with the current JavaScript syntax would likely need further refinement of tracking the various contexts of a file.
From also doing a rewrite of C/C++ (which has the nasty issue of the C preprocessor), I do believe that it is possible to build a high-quality syntax that supports JSX.
I imagine someone who regularly uses JSX would probably be best suited to the initial exploration of the idea. For now, I think it also probably deserves to live in Package Control with all of the other syntaxes.
At some point Jon and I will probably discuss the idea of adding other syntaxes, however for now we probably have our hands full with keeping the existing ones accurate and fast for highlighting, the symbol list and the indexer.
wbond
on 28 Apr 2016
Totally forgot this was still open. Sounds like a great idea Will. Something I noticed in Atom which made adding JSX syntax quite easy, was that the JSX simply extended the built in javascript syntax highlighting. That allows updates to the JS highlighting without needing to update a second package to keep them in sync. Is there some ability like that in Sublime that I've missed? When I began fixing issues with the current Babel package which adds jsx support it appeared to be the entire language rather than an extension of JS.
jontewks
on 28 Apr 2016
Yes, you can import contexts from other languages (.sublime-syntax is a superset of functionality of .tmLanguage/Atom languages).
The issue is that to properly detect various complex constructs, you need to enter nested contexts, and that nesting won't "automatically" span multiple files. Because of that, you often have to copy-paste various constructs. My hope it to at some point create a new form of "including" another context, such that it would allow for named contexts to overlay on top of each other, however that probably won't happen in the immediate future.
wbond
on 28 Apr 2016
When is it time to support JSX syntax as default?
elquimista
on 16 Mar 2017
@clthck Jon and I have discussed it, but it is not on the top of the priority list right now. I would imagine that the correct path would be for someone who is familiar with JSX and JavaScript to explore the current JavaScript syntax and provide feedback about how to identify when a JSX tag is encountered, versus a less-than symbol. I haven't used JSX, so I don't know if there are a set of basic rules about this.
wbond
on 16 Mar 2017
I created a very simple language grammar that extends javascript and offers jsx support, but it is a very crude implementation, and I am almost certain it doesn鈥檛 cover everything. I will see if I can publish it.
The problem with the existing packages for sublime that support jsx is that they do not use the proper js grammars after @wbond refactored them.
ccampbell
on 16 Mar 2017
Related issues
darkred
路
4Comments
n-kort
路
3Comments
mouse07410
路
3Comments
MiChAeLoKGB
路
4Comments
evandrocoan
路
3Comments
Most helpful comment
The built-in JavaScript syntax has gone through almost a complete rewrite at this point, with many tests. I believe at this point it has excellent support for ES6/ES2015. Please do open issues for any problems you find.
I believe that JSX should probably be a different syntax, just from a user perspective. Doing so with the current JavaScript syntax would likely need further refinement of tracking the various contexts of a file.
From also doing a rewrite of C/C++ (which has the nasty issue of the C preprocessor), I do believe that it is possible to build a high-quality syntax that supports JSX.
I imagine someone who regularly uses JSX would probably be best suited to the initial exploration of the idea. For now, I think it also probably deserves to live in Package Control with all of the other syntaxes.
At some point Jon and I will probably discuss the idea of adding other syntaxes, however for now we probably have our hands full with keeping the existing ones accurate and fast for highlighting, the symbol list and the indexer.