Color/syntax problem with classes? I could be wrong. about processing-sublime HOT 17 CLOSED

hi shmup,

thanks for the bug report!

but to be honest i don't have a clue. i "inherited" the language definition from the old processing textmate bundle by Leon Hong (there is a link in the readme and see the language definition in Syntax/Processing.tmLanguage).

Are you by any chance a regex wizard? :)

from processing-sublime.

Ah, sorry, meant to respond a while ago. I am not a regex wizard. :P

Not a big deal anyways, but just maybe a day will come where a wandering wizard will see this issue, and lend a helping wizard-hand.

from processing-sublime.

you can also write "public":

public class Walker {

}

to get rid of the odd highlight ...

from processing-sublime.

This red highlight is the source.c++ scope, which is "included" in the Processing.tmLanguage syntax definition. In C++, a semicolon is expected after the closing brace at the end of the class definition.

The reason why it disappears when you prefix public is that the Java syntax rule then takes precedence.

This is really an example of a deeper issue, about how the Processing package shouldn't (in my opinion) rely on the C++ package. However, simply removing the include causes some syntax highlighting issues that kind of "ruins" things without further work.

from processing-sublime.

Just an update on this. This is caused by the C++ syntax rule that classifies semicolon-less closing braces for class definitions as "invalid.illegal," which many color themes highlight in red.

I'm not certain yet how to override this, (perhaps using the View API's erase_region method?) or how we might remove the dependency on the C++ syntax file.

from processing-sublime.

I'm neither an expert on this ... but when tried to remove the dependency to the C++ package, quite a few things broke. But on the other had this was before you fixed quite a few things. Basically what I'm saying that I don't have a clue how to fix it. Sorry no pointers from my end!

from processing-sublime.

Yeah, it's complicated and I'm not an expert either. :) Just adding the info to this issue for a future fix.

from processing-sublime.

+1 this irked me as well, if I get a chance I will have a look further

from processing-sublime.

@ybakos is spot on with the C++ directive.

The short answer of why this is happening is that the whole processing file is being parsed as if it was a c++ file, so it highlights keywords, but it also gives an error if, for example, you don't have a semicolon at the end of your class definition. In essence anything inside of a function or a class is being styled as C++ and nothing in the tmLanguage file after the C++ directive makes a difference to the parsing of the file, except for things outside of a set of { } brackets, for example import lines.

Taking out the C++ directive broke other parts of the styling because now it was being styled as a Java file, and the styling for java doesn't do nearly as much styling around function calls (which is the reason why all the function calls turned white in your screen shot in #68 )

The problem there is that you can't inherit styling from another lexer (i.e. java) and extend it to add new embedded functionality (like adding processing keywords that get styled inside of a java class). You can only take the other language's style exactly as is, and anything you add will only affect root stuff. For example, if you use a processing keyword like background() for example, it will style as a processing keyword if it's outside of a function, and style as a C++ keyword if it's inside of a function. This is a pretty big problem in my opinion, because it means most of what's inside the tmLanguage file is actually doing nothing, and the only 2 things that do anything are the C++ and java lines, where it styles it like a mix of c++ and java, not as an extended java syntax, which is what processing really is.

One simple bandaid solution would be to change the line from including C++ to including C instead. That would preserve a lot of the things you said got broken, since any top level functions would still be styled like a C function and any classes would change from styling like C++ to styling like Java. It would preserve things like the function keywords (only in top level functions like setup()), but would stop it from requiring a semicolon at the end of a class. Unfortunately though anything inside of a class definition would now be styled as a pure java class and the styling would change (since java's styling is very lacking in my opinion). It's certainly not ideal, because you would still have inconsistent styling throughout.

The only real solution to all of this is to copy the java tmLanguage rules, and to readapt them for the processing community, adding function call styling, like C++/C has. Until that happens, there will continue to be weird styling errors since processing is not based on C++.

As an alternative, someone could submit a pull request to the built-in java language lexer to add better styling, which would in turn help the processing lexer, allowing us to remove the dependency on C++ styling without feeling like we've lost color.

from processing-sublime.

Here's an example if C++ is changed to C.

C++ version:

C version:

Notice configureUI() stops being styled because it's inside of a class, so it changes to being styled as java, but background() continues to be styled, because it's in a top level function (setup()) and so is styled as C.

For reference, this is the version without C++, so it's pure java:

Notice here, that neither configureUI() nor background() are styled, because they're both being recognized as pure java, which again doesn't style function calls.

The main thing I want to illustrate is that the reason the styling gets worse if you remove C++, is that java's lexer just doesn't style as many things as the C/C++ ones do. Also that changing it to C makes parts of it better but it still has problems, just different kinds.

from processing-sublime.

Hi @kylefleming,

Many thanks for the investigation! Finally I get a grasp of what is going on. Do you think you can fix it completely?

If not ... and as the whole thing seems to be endless and nobody is keen to maintain it (including myself) ... I would vote to remove the processing vocabulary highlighting completely from the bundle and just go with the standard java highlighting style.

Opinions?
@ybakos
@shmup
@Frozenfire92
@bertbalcaen

from processing-sublime.

I'll gladly try. My plan is to rewrite it as I described above to be based on Java with some added stylings to be more like what we have now. I'll let you know when I have something that works the way we want it, possibly the next few weeks.

from processing-sublime.

@kylefleming 👍 That would be mega! Looking forward!

from processing-sublime.

@kylefleming I am so glad that this has irked someone else besides me.

I agree that a pure syntax definition for highlighting without the C/C++ dependency would be ideal. However, if this proves to be not worth the effort, then I recommend replacing C++ with C.

from processing-sublime.

I naively think the path of least resistance here is to:

1. Remove the source.c++ include.
2. Add what we need from source.c++ to get syntax within class & method definitions correct.

from processing-sublime.

Just for reference, the problem is that you can't actually "extend" another included source. You can import it wholesale, but you can't add to the inner layers of it, so the only way to add to it in the way we want is to copy everything over from java (hence #77).

from processing-sublime.

Solved 589fb57

from processing-sublime.