Thom1729 / Sublime-JS-Custom

Customizable JavaScript syntax highlighting for Sublime Text.
MIT License
137 stars 9 forks source link

What are the major differences between this repo and the definitions in SublimeHQ/Packages? #133

Closed varungandhi-src closed 2 years ago

varungandhi-src commented 2 years ago

Hey, I noticed that you've been submitting PRs to SublimeHQ/Packages for improving the quality of syntax highlighting.

I'm in the process of fixing merge conflicts in our fork (https://github.com/sourcegraph/Packages/pull/1), which used to rely on this repo (via https://github.com/slimsag/Sublime-JS-Custom-Generated). However, since https://github.com/sublimehq/Packages/commit/40ec1f2f9b56fb55d739e17ecd003cc9e8c9b096 landed, as well as the recent changes in SublimeHQ/Packages, it looks like we shouldn't need to regenerate the syntax definitions ourselves, since the ones upstream in SublimeHQ/Packages are reasonably up-to-date.

For example, one of the things I noticed is that if I generate the definitions from this repo, the syntax definitions end up being quite big.

70728    Default.sublime-syntax
88689    React.sublime-syntax
100192   TypeScript (JSX).sublime-syntax
94906    TypeScript.sublime-syntax
70713    ~embed.sublime-syntax

Whereas most definitions in SublimeHQ/Packages are much smaller:

71274    JavaScript.sublime-syntax
5271     JSX.sublime-syntax
4394     Regular Expressions (JavaScript).sublime-syntax
1017     TSX.sublime-syntax
28230    TypeScript.sublime-syntax

Is it the case that the definitions in this repo are much more comprehensive, because they include support for new features and customization? Or are the essentially the same, except for some minor differences (e.g. the ones in SublimeHQ/Packages seem to be "hand-written" whereas these are generated)?

Thom1729 commented 2 years ago

This package is directly based on the core syntaxes from Sublime HQ. It starts a vendored copy of the core JavaScript syntax, then patches it with additional features according to your configuration. A key feature of JS Custom is that it should behave identically to the core JavaScript syntax except where non-core extensions are used.

For example, if your configuration is {"jsx": true}, then JS Custom will generate a custom syntax consisting of the base JavaScript syntax plus a set of patches to handle JSX.

The reason for the difference in file sizes is that the core JSX, TypeScript, and TSX syntax definitions are themselves sets of patches, using the new extends feature in Sublime 4. The JSX.sublime-syntax file is not a complete syntax; it contains only the added JSX functionality, and requires JavaScript.sublime-syntax to work. But JS Custom will combine whatever patches it uses into a single self-contained output file, so it will be somewhat larger than the base JavaScript syntax and much larger than the JSX extension.

JS Custom's JSX, TypeScript, and TSX extensions are, like the core syntax, vendored from core. So if you define a JS Custom configuration using only these extensions, then it behave work identically to core, and there's no real reason to use JS Custom rather than using the core syntaxes directly (assuming that the tool using these supports extends). On the other hand, if you use other extensions, such as custom templates, then you need JS Custom.

In your particular case, it sounds like you should be able to depend on the core JavaScript &c syntaxes rather than JS Custom.

varungandhi-src commented 2 years ago

Thank you for the thorough answer!