| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
So far I've been trying to make Teliva follow the default colorscheme of
the terminal, but that easily ends up with illegible color combinations.
New plan: always start with a light background within Teliva. People who
want a dark background will currently need to mess with C sources.
This should somewhat fix https://github.com/akkartik/teliva/issues/1.
It's still not clear whether the default should be a dark or light
background. While dark background is more common in terminals, I believe
newcomers to terminals will prefer a light background. Then again, I'm
biased since I use a light background in my terminals.
|
| |
|
|
| |
This is essential when debugging.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
When installing using NixOS[1], the screen looks wrong. It looks like
attrset(A_NORMAL) does not undo color changes with some versions of
dependencies.
[1] https://github.com/marianoguerra/marianoguerra.github.io/blob/master/advent-of-future-of-code/days/day-02.md
|
| | |
|
| |
|
|
| |
Thanks sejo.
|
| |
|
|
| |
https://archive.org/details/akkartik-teliva-2021-11-30
|
| |
|
|
|
|
|
|
| |
I wish I could just hide KEY_BACKSPACE and prevent myself from using it
by accident.
Then again, I'm not making this smarts available in Teliva programs
themselves. Just for the Teliva environment.
|
| |
|
|
|
| |
Kilo likely never ran into this because it's only been tested on C,
which uses semi-colons at the end of each statement.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Short of syntax errors that keep us from parsing the teliva_program
table, we should now be able to recover gracefully from everything.
Yesterday I started to try to add this to load_definitions before
realizing most errors are only noticed while running `main`. But I
didn't think of recovering from the docall of `main` until this morning.
|
| |
|
|
| |
It was printing a phantom null at end of line on screen.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It makes me very nervous now that there's save_editor_state within
editor event loop, when the editor could be editing notes. Things are
slightly better than this morning, but this prototype still suxxors.
|
| |
|
|
|
|
| |
I think I've gotten rid of all the segfaults, but it's still pretty
messed up: if you hit ctrl-g and go edit some definition, it doesn't get
saved. You're just storing the edit in the note.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm mindful of the way abstractions can create duplicate effort:
https://flak.tedunangst.com/post/browser-ktrace-browsing
== Kartik's SAD theorem
As programs grow complex, you will be repeatedly forced to either:
- maintain some State,
- perform some computations Again,
- or Duplicate some code.
Here a small amount of duplication seems like the best alternative.
Particularly since no syscalls are involved.
|
| | |
|
| |
|
|
|
| |
I'm going to give up on hiding teliva_editor_buffer from kilo. It was
taking too much knowledge of extern function prototypes on both sides.
|
| |
|
|
| |
Also rename it appropriately.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the spaghetti is hiding another issue: when we load editor state,
that code path currently never leads to importing the edited buffer back
into the image.
Yet another attempt at drawing the state diagram:
Wgetch -> switch_to_editor -> select_view
select_view -> load_editor_state | big_picture_view
load_editor_state -> edit_from -> editorProcessKeypress
big_picture_view -> edit_image -> edit_buffer -> resumeEdit* -> load_editor_buffer -> editorProcessKeypress
big_picture_view -> recent_changes
recent_changes -> big_picture_view | edit_buffer
The problem is that load_editor_state doesn't eventually call
load_editor_buffer the way its sibling big_picture_view does.
For starters, it's confusing that switch_to_editor calls
big_picture_view which calls other editor functions. What is 'editor'
here, anyway?
Let's rename switch_to_editor to developer_mode. So the app starts out
in user mode, and might eventually transition to developer mode.
Developer mode is a black hole; to leave it and return to user mode we
restart the entire app.
The architecture in my mind is now:
- Teliva consists of user mode and developer mode
- Developer mode consists of multiple views
- Each view, when it needs to edit something:
- initializes kilo
- loads a buffer into it
- resumes editing the buffer as necessary
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My code is already at spaghetti levels. Some coping mechanisms.
===
The big problem with the Teliva approach compared to my previous Mu
project: no tests. At this point I should document the growing list of
manual tests I've been maintaining:
run a program
run a program, edit
run a program, edit, make an edit, run | edit takes effect
run a program with error
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 A -> move cursor -> run -> exit -> start -> big picture -> edit B | cursor initialized
start -> big picture -> edit A -> move cursor -> run -> exit -> start -> big picture -> edit B -> big picture (*)
syntax highlighting for line comments
syntax highlighting for multiline comments
(*) - fixed in this commit
===
Coarse-grained state diagram (ignoring recent_changes_view):
app -> big picture on ^e
big picture -> editor when selecting a definition
editor -> app on e
editor -> big picture on ^b
Fine-grained sequence diagram:
main -> pmain -> ... -> Wgetch -> switch_to_editor -> select_view
select_view -> load_editor_state, falling through to big_picture_view if needed
load_editor_state -> edit_from -> editorProcessKeypress
The consequence I hadn't fully internalized was the return path:
editorProcessKeypress -> edit_from -> big_picture_view
Which implies that load_editor_state fails in two ways:
- when the state doesn't exist or is not applicable or is corrupted
- when editing from the state explicitly requested the big picture view
Switching the return value semantics for load_editor_state now supports
both ways.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Making changes to lcurses directory was causing it to be compiled, but
not causing teliva to be relinked.
Now I'm:
- unconditionally running `make` on subdirectories
- conditionally linking their outputs
Seems reasonable when I put it like that. Hopefully this is working now.
I used to know `make` down cold a decade ago, but it's evaporated from
my brain.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Teliva's constantly restarting without the user being aware of it. So
far I figured saving history across the user actually exiting and
restarting Teliva was just a happy "feature". However, it looks like
that's actually more complex to implement. Keeping editor state across
user-visible restarts results in these problems:
- opening the editor after restart has the cursor position messed up, no
matter what definition you open.
- more seriously, opening the editor after restart can't seem to get to
the big-picture view anymore.
Rather than try to debug what's going on, I'm going to just cordon off
that part of the state space for now.
|
| | |
|
| | |
|
| |
|
|
|
| |
We still need a proper story for file system side effects. But it's not
time yet for sandboxing considerations. Soon, but not yet.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're not using this yet.
I agonized over this decision for several weeks. Is Teliva's need to
restart with execve an utter hack or a good thing? I'm leaning towards
the latter. Constantly exercising the initial flow makes Teliva more
crash-only. We can build Steve Yegge's idea of immortality (http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html)
out of crash-only primitives, just by making reboots instantaneous. But
focusing directly on immortality tends to compromise crash-only by
exercising it more rarely.
One other issue this brings up: loading these Lua tables from disk is a
vector for arbitrary code execution. I need to fix these when I get to
sandboxing.
|
| | |
|
| |
|
|
|
| |
I'm deliberately restricting this incompatibility to the editor
environment for now.
|