| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Still emitting a bunch of warnings on OpenBSD, though.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I'd like to enable -Wextra as well, but that creates some false
positives.
I've at least made my changes clean w.r.t. -Wextra.
Now we have 4 remaining warnings with gcc 9.3 that seem genuine. Need to
fix those.
|
| |
|
|
|
| |
No distinction now between the C and Lua versions of the curses library.
We build them all together in one place.
|
| |
|
|
| |
From lcurseslib.c to lcurses/ directory.
|
|
|
Until now we had just the bare minimum bindings needed for the demos
built so far. Now we have all of lcurses building in place with minimal
changes.
The changes in this commit can run hanoi.lua when inlined into Lua 5.1,
but don't work with Teliva.
|