"What, you're not even have a 1.0 out and are already talking about 2.0?", you ask. Well, yes! It's much more fun to think about the future!
One of my goals has always been to have as much as possible of the functionality on the Erlang side. This is simply because I prefer to code Erlang than Java. The reality of having to learn coding for Eclipse has made it difficult to pursue, one of the main reasons being that a lot of the boilerplate code is loaned from the Java Development Tools plug-in.
We have been slowly refactoring functionality to Erlang, but for 2.0 I see a different approach: implement a code handling engine in Erlang that really could use anything as a GUI. The API will probably be heavily influenced by the Eclipse way, but I can live with that.
So, what I have in mind is something like this:
- the GUI sends notifications when there some editing event
- the engine keeps a representation of the document in memory
- the document is linked to a lexical scanner and a parser, for each change these will update their model of the source file
- a higher-level model willl keep track of dependencies between files and their changes
Now, for the real work we will have extensible services, for example:
- lexical info: tokens at a given position/range, ...
- syntactic info: matching braces, ...
- semantic info: language constructs at a given position (AST), ...
- search: find definitions and uses of variables/functions/macros/records, ...
- indentation
- formatting
- completion
- annotations: warnings/errors from different tools (compiler, dialyzer,...)
- refactoring
- ...
The GUI will use these services and render them in an appropriate way, and of course will convert user input into the respective queries to these services.
Some of this functionality is already in place, but there's a lot of duplication and uncoordinated work. It's this that needs to get cleaned up.
Posts
