src/teliva counter.tlv
C-e # switch to editor
C-e # save and quit
C-x # exit
counter.tlv now has the same logical contents, though the whitespace has
changed, and the order of keys is different.
The implementation is utterly ghastly. For one, I'm unnecessarily
interfacing with kilo through the file system.
Plan is for this to be the default representation for Teliva programs.
Text-friendly but not meant to be edited directly as text. Will
eventually include both code and data definitions, both current snapshot
and past revision history.
Right now .tlv files seem to run. Error checking is non-existent,
because I don't understand Lua's idioms around 'status' yet. Opening the
editor expectedly segfaults.
This commit is the most mind-bending bit of code I've written in a long
time.
one more implication:
- the menu table. It feels natural to define it alongside keyboard
input. However, it may then not be initialized during the first paint
of the app.
I'm not sure how I feel about the menu data structure being defined far
away from the `update` function. Recipe for it to go out of date.
Current plan: definitions can have arbitrary code. They'll be loaded
lazily when a specific name is invoked but has no binding. Implications:
- It'll be the responsibility of the code to define the name it's saved
in. "Phony" names will result in some fragments of code repeatedly
executing.
- Assigning a global to nil is a way to retrigger its initialization the
next time it's needed.
I'm not sure how I feel about this sort of incompatibility with Lua. I
suppose we could avoid it by also tracking what definitions have already
been loaded in a run.
Before we'd end up in cryptic situations where error messages would get
hidden when the program got out of ncurses mode.
Now it's a little nicer with error messages showing up at the bottom of
the editor.
But there's still a problem: there's no way to abort without fixing an
error.
Kartik K. Agaram