bitwrite
Last visisted [2020-11-02 Mon 10:30]
keywords: bitwrite 1bit hypercardtypewriter kilo SDL.
Overview
A work in progress concept, that all started with an idea:
2020-08-04 12:33:52: an extendable text editor inside of a Blit that tries really hard not to edit text. #halfbakedideas
This, combined with my 1bit aesthetics, led me to come up with this concept I'm calling "bitwrite".
Goals
The main goal is to build a means for me to boostrap my way into buildinng graphical user interfaces from my familiar keyboard-driven workflow. The idea is to build things that are a bit better than the TUIs you'd see made by ncurses, but not as sophisticated as something like imGUI. I also hope to give the system a simple core with a very flexible C API. That way, bitwrite can be easily modified and extended.
Process
The whole process starts with the wonderfully simple Kilo text editor, and porting it to a simple bitmap GUI via SDL 'and btprnt. Bitmap fonts will be baked in using the xbm format.
Kilo internally treats text internally as a set of rows. Instead of writing to a text file, Kilo will be modified to write to a SQLite database as a kind of file format. This is where Kilo stops being a text editor, and starts becoming a text interface. With any luck, this approach will allow for more extendability of bitwrite, and also help better integrate with my existing software that also uses SQLite.
A command language will be added. Hitting alt-enter on the current line will allow the line to be evaluated by this interpreter.
Kilo structures things in terms of rows of text. Instead of text, this concept of a row will be expanded to be a region of pixels. A program interface will be written that allows a row to be occupied and written to in any arbitrary way. Not just text. The row height can be adjusted, but the width will remain fixed.
New programs can be save/loaded to the SQLite file.
Updates
2021-02-09 13:56:26: how would this structure work in C? would it also still keep rows flat with hierarchy stored elsewhere? things to think about.
2021-02-09 13:55:10: in org-mode, it is possible to notate headers that skip levels. Which isn't all the helpful. I think it's better to keep things all relative: nodes are responsible for knowing who they belong to.
2021-02-09 13:52:32: maybe some other table that references the ids from the raw rows table. the row order will always be the same, it just either goes up or down a level.
2021-02-09 13:50:28: the first big modification I see is changing the file format. Instead of text files, it's going to be a self-contained SQLite file. The path of least resistance here is to make a table to store each line with their position. Then somehow we add something on top of that that enforces hierarchy.
2021-02-09 13:48:00: working with kilo kind of feels like working with a ball of clay. it's malleable, yet finite. prepared. kilo already is built a certain way, and to get it to do what I want it to do involves gradually adding modifications to it.
2021-02-09 13:25:27: the hard part, as I see it, is trying to work that into the existing kilo code. I don't actually know fully how the kilo system works. it stores text in sequential rows. but how hard would it be for rows to become tree nodes with rows in them?
2021-02-09 13:23:55: I'm beginning to think that I want bitwrite to be about controlling a tree of collapsable (folding) text blocks that can also be evaluated as commands to modify the internal state of the tree.
2021-02-09 13:20:48: lost but not forgotten. as things like (zet), (crate), and (zetdo) are growing, the need for something like bitwrite is becoming more necessary.
2021-01-16 21:51:08: Bitwrite still needs a good data structure. I've been thinking about a tree to mimic outliner programs like org-mode. Somehow getting the graph format like \!zet to work would be pretty dope though.