What I would like to see for ANTLR4/ANTLRWorks is the automatic generation of an editor / editors that support(s) users of your language in writing correct input for it. A little bit like Xtext, but far more light weight and not embedded in Eclipse or any other IDE, but rather standalone. Also target audience would be extended to non-programmers and users of non-technical DSLs.
Would be best to keep the generated stuff both basic at the technical level and easy and obvious to use. It should still be possible to extend the generated stuff using extension points.
What would it do for the user using the grammar only
There is a couple of information already present in each grammar you write which an editor could make use of.
As I have been told ANTLR4 carries around enough runtime information to know which tokens can follow at any given point of the users input. This would allow for automatic code completion.
The editor could also know what is a keyword and could do some syntax coloring based on that. At least giving all keywords a different color than non-keywords.
Summing up:
- syntactic code completion
- syntax coloring
- display of errors
What UI library/framework/technique would it use?
As we require a solution that works standalone, Swing is the first thing that comes to my mind. Even though there is a tendency towards web based solutions in all areas, I still guess that most software development is done offline on your local machine. But, if we think of non-technical DSLs which might even be part of a web application, such an editor would have to run in the browser as well. This would either require the ANTLR 4 runtime to run on the client or that it is coupled via remote calls. In either case, the client frontend itself would have to run in the browser. The most natural choice for me would be GWT then. Maybe, if you fancy rich, desktop like front ends Ext GWT might also look interesting. Due to its partially commercial approach Ext GWT might cause trouble, though.
What would require additional information / code
There are a couple of useful things that might be solvable using a simple treewalker that has access to additional context information
- more advanced syntax coloring
- code formatting / indentation
- semantic errors / warninings
- quick fixes
It might make sense to have a simple interface that can trigger actions on your input, either to simply make modifications on the source level or to fire of compilation or interpretation.
What would be hard to do
Refactoring
Basically, everything that would require to update the source based on parse tree / AST modifications. Most and especially more complex refactorings are very hard to do directly on the text without using structured information. Also quick fixes that require analyzing and updating the parse tree fall into this category.
When making modifications on the parse tree, you need the ability to completely reconstruct the input source from the parse tree. Additionally, you need to know which whitespace belongs to which token, e.g. in order to keep indentation of stuff you changed while refactoring.
Semantic code completion
If you open your Java IDE you will find, that most of the time the code completion you benefit from is not a syntactical, but rather a semantic one. By semantic code completion I mainly mean type information and information about existing structures. Given your language has types in the first place, it would be crucial to have type system that you can query about what types are defined and which types make sense in which situation. Also, if your language allows to defined structures or deals with structures, it can be very convenient to tell the user which parts are in which structure - like which fields there are in a class. This requires a lot of information that you will have to provide to the editor using a general extension point. Not sure at all, how such an extension point would look like.
How to integrate with ANTLR
The editor would probably be based on the ~admin:/2011/09/08/Sample v4 generated visitor. It contains all information to display errors found in the input to be rendered at the right position in the editor using line/column information from the tokens.
It also works the other way round: You have the cursor at a certain position in your editor and the editor can find the token inside the parse tree. Having that information you can query the runtime grammar which tokens might follow the current one. This would make it possible to offer code completion suggestions. Might be best to display the choices after a certain delay.