Rebuild the processing syntax highlighter using java as a base

[kylefleming]

@b-g @ybakos Give this version a try. I did a screenshot compare of some of my pde files and in each case the highlighting was improved and no highlighting was lost from what I can tell. Hopefully you find the same results!

Here's what I did for reference:

• started with java as a base
• took out java's "enum" and "package" (not supported by processing)
• added C++'s function call highlighting
• put back in processing's keyword highlighting

Here's a comparison to the screenshots I took in #20:

(and for completeness here's it compared again to the current processing highlighting)

[ybakos]

Awesome! However, two issues I see are:

1. We should keep enum and package.
2. Unwanted italicization of data types.

[ybakos]

I see now - maybe the italics in the screenshot are just part of your particular config. (In mine, datatypes are not italicized.)

[ybakos]

@kylefleming , actually I redact everything I said and I do like your approach. Every other way just doesn't make sense. Thank you soooo much for working on this. There are some minor issues, which I will post here and also add line-by-line comments to the source.

[ybakos]

@kylefleming I've now spent significant time with this. Thanks again. I have one humble request and one potential flaw to point out. Screenshot below illustrates.

1. Let's ensure that enum Foo behaves like class and interface.
2. Dark color themes (eg. Amy, others) tend to incorrectly highlight parens and/or braces. May be a bug in the relevant regex.... or perhaps the color themes themselves, but I'm mentioning it here. Screenshot illustrates.

I'm personally no longer concerned with the way package is/isn't handled; the default actually seems aesthetically pleasing across many different color themes.

[ybakos]

@kylefleming (sorry to be so chatty) You can ignore my comments regarding the inconsistent parenthesis highlighting. This is really an issue of the particular color theme.

I guess the only issues to discuss are:

1. Adding enum to the same / similar rule as class and interface.
2. The impact of changing source.pde to source.processing.

/cc @b-g

[kylefleming]

@ybakos I'll answer your questions in order:

• enum/package highlighting: if you try to declare an enum or declare your file belongs to a package, in both cases you get a compiler error. The reason I can see to keep it is if we wanted someone to be able to select the processing highlighter for a pure java file. On the whole, it doesn't hurt to add them back in, so either way is fine with me. I notice in your screenshots you have these declared listed. Do those files compile?
• italicized data types: From what I can tell, for data types of a variable declaration, java uses the style identifier storage.type and c/c++ uses variable.other. Given that the color scheme can style each identifier however it wants, your theme probably styles the 2 identifiers exactly the same while the one I'm using (Monokai on sublime text 2) probably italicizes one of them. We can change it to match what was there before if we want, for this issue too I think either way is fine.
• Just for reference, I also want to mention that I changed the base of the processor to start at "class-body" instead of "code". class-body includes code so it will be backwards compatible, but this is representative of how processing works, since all of the code in the pde's are essential embedded in a global PApplet class. The styler now reflects this and lets you do things like declare methods on the top level (like setup()) which isn't possible in java.
• I agree we should take out java only classes. But also those classes are styled for me the same way as a normal class, so I'm not sure that they're even doing anything right now. I think it will need more investigation. In general though, I agree only processing specific classes/constants should be highlighted differently.
• Inconsistent paren highlighting: That's an artifact of the copying the function call highlighting from C, where it styles the first parenthesis as punctuation.definition.parameters. It's easy to take out and probably should be taken out, or we should highlight the end one too. The easier route is to take it out though.
• changing source.pde to source.processing: From what I could tell, other languages all declare that as the name of the language not the file extension. I changed it to keep consistency. It doesn't make a difference in the grand scheme of things, though. If we change it to source.processing, we should also change the build scripts and anything else that depends on it. Otherwise, changing it back is fine too.
• Another change to note: I changed the postfix of the style identifiers from .java-processing to .processing. This again is for consistency with other languages. (and side note I see I forgot to change the C ones.) There may be side of effects of this change, but I'm not away of any.

[ybakos]

Thanks @kylefleming . I think in this PR we should keep it focused to the issue at hand and ignore my comments about the Java classes, etc.

I think it's wise to:

1. include the enum stuff (again, ignore what I said about package).
2. Perhaps make the source.processing change in other locations.

Care to create another PR with those two changes, and close this one? (@b-g will probably chime in soon).

[kylefleming]

@ybakos Thanks for the code review. I added a new commit to this pull request with these changes:

• I switched back to source.pde. I figure that the config files of people's machines are probably already using source.pde for things like "always open this file as" and stuff like that. Better not to break it.
• I put enum and package stuff back in. Since the processing language file declares it can open java files, it's probably best to make sure it styles them the same as the java highlighter would.
• I removed the part where it styles the first parenthesis of a function call differently. Good catch.

[b-g]

Merged!

@kylefleming Many thanks for taking care of it! Finally working syntax highlighting! I added you to https://github.com/b-g/processing-sublime#acknowledgements

@ybakos Thanks for feedback, code review and spotting!

[ybakos]

@kylefleming Awesome, man. Thank you!

[kylefleming]

I'm glad it all worked out, happy to have contributed!