ghost
commented
6 years ago I'm not necessarily against this but I think there are some issues to consider first.
One of the things that makes the Reason and OCaml highlighters in this extension unique is that they accurately handle different syntactic categories of identifiers which are usually not distinguished in most other highlighters. For example, module paths, data constructors, record fields, etc. are (modulo bugs) highlighted accurately. It's only possible to do this if the highlighter actually parses the syntax.
Most highlighters, including the Javascript highlighters I've seen, don't do this. To some extent I think this is due to the fact that it's just hard to build a parser into a TextMate grammar. But I think it's also because most languages don't have as many syntactic categories as something like OCaml. What most of the Javascript highlighters do instead is they handle literals and a few easily distinguishable things like declarations and definitions and then do some keyword highlighting.
So there are two possible approaches I could see for what you are proposing here.
The first would be to drastically simplify the highlighter (rather than port it to the newer style I am using for the OCaml highlighter) and basically just do what some chosen Javascript highlighter does. I think this would make it very difficult to accurately highlight some things like module paths, record paths, perhaps even types. I also tend to think that unless you were to just port an existing Javascript highlighter, it will be quite a bit of work to start over in this direction.
The second would be to still do the accurate parsing but to try and match the colors or scopes. I think this would be feasible to some extent but I'm also fairly confident you would end up with a highlighter providing less useful information overall. The thing is, there are only so many TextMate scopes that are available across most themes and editors and the current color scheme tries to make maximal use of those. What will happen is some things distinguished with different colors in the current highlighting scheme will no longer be distinguished because some scopes will have to be reused. For example, you might have the same colors used for module names and data constructors or pattern variables and types.
On that last note, it's important to realize I didn't set out to make the highlighting look different per se. That's really just an artifact of trying to provide the most informative highlighting within the context of the haphazard nature of how TextMate highlighting has evolved and whats available in most themes.
I spent quite a lot of time trying to figure out how to get the current highlighting scheme to work in a stable fashion across most editors and popular themes and still provide the most information possible. The current OCaml highlighter does a bit better job of it I think (since I had a better way to construct the grammar after the rewrite).
One last thing: I think that if we did an actual comparison of what Javascript highlighting looks like across Atom, Code, Sublime, etc., with a handful of themes (trying to match across editors where possible), I suspect it would illustrate that there's already quite a bit more variance than the average user might expect.
Atom, Code, Sublime, and other editors all use different Javascript highlighters, and that's not counting the 3rd party ones available as extensions. So which combination should serve as the model?
Of course, one can try to make the Reason highlighting with any given editor + theme look as close to the Javascript highlighting as possible, but it may be difficult to do that without reusing the Javascript highlighter itself to begin with.
Anyway, I just think these are some things to keep in mind for this discussion.
By the way, it is also possible to have multiple options for highlighting. In principle, I guess we could always just offer both a JS-like highlighter and an accurate highlighter if there was enough interest in doing that. I think to make that work we'd need to move the highlighting part out to a separate extension (at least one of them, maybe both).
chenglou
Once the new syntax comes out I think we should change the strategy for syntax highlighting. Instead of building from scratch and trying to be correct/complete, we should work to mirror the JS syntax highlighting as perfectly as possible.
I think this is one case where being technically correct is less important than being familiar. People are used to seeing JS in default Code/Atom syntax. If our code looks and feels like JS then we should have the syntax highlighting to compliment it.
Reason (we should not map the highlighting in the second line to look like the first):
JS (we should make the bottom line above look exactly like this):
@chenglou PS: sorry - I used Atom for this screenshot but the same idea applies across all editors :)