This is in response to Fry's status report asking for feedback/suggestions, otherwise I'd probably consider most of this stuff too trivial to bother you with, but since you asked...  

There are a few oddities in the syntax highlighting.  Particularly, where functions and variables share the same name (fe, mousePressed, keyPressed, frameRate) the functions are colored as if they were variables.  (keyword/literal confusion)  So while mouseReleased() shows up in brown (because no variable of same name), mousePressed() shows up in red.  I don't know the internals of the highlighter, but am wondering if it has the ability to do a "read-ahead" one character and try to find that opening parenthesis to resolve the difference?

Also, it's nice to have the full list of Java keywords highlighted, but it isn't clear what does/doesn't merit inclusion in the reference.  Not a big deal, just another discrepancy nitpick, because you asked.  For instance, "double" and "long" don't show up in the datatype list.  Or why "implements/extends" both merit inclusion in the reference but "abstract" doesn't.  Or why "for/while" both merit inclusion but "do" doesn't.

Then there are a few Java classes/packages, like "Math" or "Thread", that get highlighted, but the list of what's known isn't obvious.

Then there are a couple of things that I'm not sure if are "officially" part of the API so maybe they shouldn't hightlight.  But they're publics in PApplet that seem like they might have been intended to be API stuff, so maybe they should?  It's often by comparison against something that IS highlighted that the discrepancy appears, fe...
"focused" yes, but "focusGained()/focusLost()" no
(constrast with mousePressed,mousePressed(),mouseReleased() where both variable and events are lit)

Then some things may be access level issues (which is really another topic).  So publics like "firstMouse", keyEvent/mouseEvent are available, but maybe they're not highlighted because they're not meant to be used as publics?  For example, if end-users ain't 'posed to be mucking around with keyEvent directly, maybe it should be protected/private?  I really hesitate to suggest you lock down access more than necessary, because I myself seem to frequently grab undoc'd publics and mess with them.    (even if just using them as "constants", for example g.cameraFOV is nice to be able to read)  I'm just bringing it up in case any are stuff that should be highlighted.