Yeah, I know Java isn't sexy, but the exe wrapper would add next to nothing to the overhead. It's literally a stub win32 app that launches a JVM via JNI. The stub itself has virtually no state.
92 instances of Scite? That's impressive! If you don't mind me asking, are you really working on 92 separate projects? I assume they're separate projects since you stated each instance has multiple tabs open. I'm pretty sure you're the edge case with that usage pattern though.
To answer your questions, yes - the GitHub project contains the parser used for squiggle-underlining of syntax errors. In fact, that's arguably the largest part of the code. As I do not have access to the ZQuest source, it's a completely homebrew parser, and so certainly does not catch everything. I think it's a really good start though. Check out the org.fife.rsta.zscript.ast package if you are interested.
The parser not only identifies syntax errors, but also produces an AST, which is then used for the tree view of the code in the editor, as well as the code completion.
It does not currently do the things you mention - infinite loop detection, etc., but that all could be added easily enough.
The code completion is also file-specific; if you have multiple ZScript files in a project (which I assume you can do), the editor is currently unaware of functions or variables defined in other files. You won't get syntax errors for such things though, they'll just be ignored. The editor is aware of the "standard" headers - std.zh, string.zh, etc. - and will provide code completion for them. So I would imagine project support would be possible simply by keeping track of all user-written script files as well.
Duplicate variables are currently identified, though as a warning (I didn't know whether shadowing variables was an error or warning). That's not done for functions but that would be trivial to add.
And thanks for your offer for doc on the lexer. I've always wanted this thing to use the actual lexer used by ZQuest, so I didn't have to roll my own. That would be hugely beneficial. However, I'm sure it wasn't written to be consumed by external applications and it isn't necessarily simple to do so. There's a difference between a standard compiler and a language parsing library. But I figure ZScript is a relatively simple language and as such isn't hard to write a new parser for it. And I really need to build an AST for code completion anyway.
Let me know if you want any help porting this guy, or have any suggestions for enhancing what's currently there. I really like this project and think there's a lot of potential to create a nice development environment for ZQuest. I've got my hands in a lot of pots at the moment but I'm willing to help out with this.
