3. It can be used to edit files (but very experimentally!)

Framing information inside buffers

I have skipped having frames and windows. Each buffer now contains the information about where on the screen they should be drawn. It is a compromize having view data as part of the model data. But is is just so much simpler. I do not have to keep track of the correlation between buffers and frames. Now, when I buffer is changed I just send it to paint-buffer function.

Drawing

The drawing to screen mechanism have been improved. Buffers ready for paint are queued and drawn using first-in first-out principle. If a newer version of a buffer enters the queue while there is still an older version present, the older version will be removed. There is no reason spending time drawing something that is already outdated.

Any buffer can be drawn anywhere. That is an easy implementation. And it also makes it very easy to draw temporary buffer in the middle of the screen if needed. Window handlers can be implemented later if we want to automatically organize windows. But there is freedom to implement any solution.

Functionality

:buffers will list buffer to select from :e <path> will open a file (no typeahead yet) :w Will save the open file (No warnings!) c p p will evaluate selection or sexp

On startup there is an "output" buffer. It is just temporarily, for easier testing.

Lumo

Lumo is not up to par with clj. The clj version is better and faster. But I try to keep Lumo in the loop. It will make it much easier to port it to ClojureScript later on. (Sometimes I vision a browser version reading and writing to and from a database. Including loading code/extensions from a database. But that is another story.)

Editor

I am narrowing in to a design where functionality is "registered" in the editor.cljc. This avoids circular references when the editor needs to know about the modes and the modes needs to know about the editor. I am extending this concept, so also keyboard input functions and window painting functions are registered. This means that the editor is told from the outside which functions to use for different task. I find this very extensible. The editor just calls paint-buffer without having to know how and where the buffer is drawn. Maybe it is a terminal, a JFrame, some http endpoint. (Oh there is room for a lot of crazy ideas.)

Next up

I am looking into syntax highlighting and trying to read other peoples solution to make an implementation that is familiar to others. Maybe I will reuse the one from liquid until my experiments are done.

Overall

I think the experiments so far are promising. At the same stage, when I developed Liquid, it contained more code lines and harder to read code.