General refactoring

[withoutboats]

This relates mainly to #23 and #52.

Frontend/Backend

Currently, the use of a rustbox interface is pretty deeply entangled with text manipulation; this seems inadvisible - if iota is successful enough, people will want other interfaces (such as graphical ones). The user interface and the actual editor should be isolated from one another.

I would propose to have the front end and back end communicate over a fully developed query language as described in #52. The back end will essentially be an interpreter for the query language; the initial front-end will be a termbox interface which produces query semantics from the user's terminal interaction, but other front-ends could ultimately be developed which are programmatic or otherwise different.

Query interpretation contexts

Currently, the structure of the program is that an editor owns a view which owns a buffer and a uibuf; user input passes through the editor to the view which results in changes to the buffer, then the view draws a portion of the buffer to the uibuf. Instead, the core of the back-end should be a dispatcher which owns all the buffers that have been loaded (accomplishing #23). It listens for queries and performs the first step of interpretation: determining the context in which the remainder of the interpretation should be performed. It then creates a separate thread which performs the interpretation and passes a result back - this result is then sent back to the client.

The context of the interpretation includes two main components: first, the buffer the query is performed on, and second, an editor/view environment which determines the rules of interpretation. I am not certain, but I suspect that there will be reasons to implement multiple different environments, so there should probably be an Environment trait which each environment implements. The "SELECT" query, for example, could be interpreted in a certain environment with syntax highlighting, or without. Again, the environment and the target would be determined by the dispatching component from the query or some stored config information.

[pythonesque]

All of this sounds pretty good to me, particularly the frontend / backend separation (something I was musing about earlier today).

[gchp]

Yep, sounds good to me too. I've been thinking about this for a while, specifically the frontend/backend thing. I was toying with the idea of using conrod as a GUI frontend and rustbox as the terminal frontend.

[gchp]

I've just committed an initial cut of a Rustbox frontend. All the drawing happens in there now. It definitely needs more work, but its a start. Let me know what you think!

[gchp]

Actually, it handles all the keyevents and the drawing. I need to clean up the initialisation, then the next step will be to implement the querying, which I'll need to think a bit more about...