There's some worrisome memory corruption here between the call to max-stack-depth
and the callee picking up its args.
All this code is incredibly ugly as I start to wrestle with the challenges
of structured editors. I keep wanting to keep business logic separate from
rendering, but there are feedback loops from wanting to know where to render
the cursor. And I haven't even started trying to avoid full-screen renders
yet. That'll complect things even more. For now the data path for every
iteration of the render loop is:
process key
compute max depth needed (or any other global information needed for rendering)
render
Simplify the app for now.
I'm not actually sure what sort of language I want to create here. So let's
not get ahead of ourselves inventing a whole new grid model and everything.
So far I've been assuming that read-key only works for ascii, and that
I'd need to get more sophisticated both for multi-byte utf-8 and multi-byte
terminal escape codes like arrow keys. Rather to my surprise, both work
fine. We just need to adjust the types to reflect this fact.
tile is already visibly slow (49x212 screen) :/ So programmer needs more
control over performance.
But this may not be the right approach. That extra flush-stdout in tui.mu
suggests it's either going to be finicky, or we have to flush on every
attribute change. And going through a buffered-file may be slower. May.
Fix a couple of subtle bugs.
- the VM was conditionally reading from the instruction stream, so that
other bugs got masked by decoding errors.
- push-n-bytes was clobbering eax.
Kartik Agaram