- Browser based editing support (with contentEditable) with respect to syntax highlighting.
- Syntax highlighting with respect to syntax-/lexer-errors.
- Resynchronization after syntax-/lexer-errors.
- Code completion.
Semantic reasoning is currently not implemented.
Implementation overview for syntax highlighting and code completion
From the user input it generates a parse tree (not an AST!) and traverses that as part of a classic visitor strategy (Turtle.g). After that the generated code is being integrated in the editor. Editor integration involves two things: Replacing a fragment of turtle-code with generated code for the exact same (but syntaxhighlighted) code fragment but also preserving incorrect code for which there no representing node in the parse tree.
A vocabulary can be deployed on any domain which is inherently incompatible with the Same Origin Policy. Code completion uses a local webserver to work around that restriction. The webserver component uses Sinatra and acts lika a proxy to the actual vocabulary resource. A nice replacement for this would use CORS to perform a lookup. CORS doesn´t need a local webserver.
Indeed that ajax request itself is asynchronous but the callback handler needs to instantiate a new parser instance to perform the translation. To prevent a user from typical blocking effects I decided to implement that component with a WebWorker.
Starting the local webserver
If you want to use code completion you´ve to start a local webserver which uses Ruby 1.9 with Sinatra. If these dependencies are available just type "make s" to start the webserver.
If you don´t start the webserver you can still rely on syntax highlighting in the editor.