08c49b5a0a
There's a separate open question here of where Teliva should store files like teliva_editor_state and teliva_editor_buffer. One school of thought is that apps should never be dropping crud into people's directories. On the other hand, I'm kinda encouraging people so far to just run apps from Teliva's directory. Perhaps that makes it ok?
40 lines
1.9 KiB
Plaintext
40 lines
1.9 KiB
Plaintext
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
|