run a program
run a program, edit
run a program, edit, make an edit, run | edit takes effect
run a program with error | big picture
run a program, edit, make an error, run
run a program, edit, ^g to a different definition, make an edit, ^e to run again
run a program, edit, ^g to a non-existent definition
run a program, edit, ^g to a different definition, ^g to a different definition, ^e to run again
start -> big picture -> edit -> move cursor -> run -> edit | cursor preserved
start -> big picture -> edit A -> move cursor -> big picture -> edit B | cursor initialized
start -> big picture -> edit -> move cursor -> run -> exit -> start | big picture (optional)
start -> big picture -> edit A -> move cursor -> run -> exit -> start -> ... -> edit B | cursor initialized
start -> big picture -> edit A -> move cursor -> run -> exit -> start -> ... -> edit B | big picture
syntax highlighting for line comments
syntax highlighting for multiline comments
start -> big picture -> recent changes -> add note -> save | note visible
start -> big picture -> arrow keys* | always exactly one definition highlighted
It's very important not to leak space on the Lua stack, particularly
proportionate to keypresses. That's a recipe for segfaults.
This implies that bouncing around between big picture, editor, recent changes,
running app.. shouldn't grow the call stack either.
== security/privacy
program draws over menu -> getch -> Teliva menu is still visible
app tries to read/write sensitive teliva files (teliva_edit_buffer, etc.) -> never allowed
TODO should we protect .c sources?
TODO protect against DoS attack filling up disk
assumptions:
listing files in a directory is not worth sandboxing
since reading their contents is sandboxed
and since UNIX permissions protect system directories
rmdir() is not worth sandboxing, since it only succeeds on empty directories
no need to sandbox unlink() since it's not exposed