about summary refs log tree commit diff stats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* inline an unnecessary functionKartik K. Agaram2021-11-281-7/+2
|
* start streamlining architectureKartik K. Agaram2021-11-282-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix going to big picture after saving editor stateKartik K. Agaram2021-11-281-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* yet another fucking makefile bugKartik K. Agaram2021-11-281-1/+1
| | | | | | | | | | | | | | 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.
* clear editor state across user-visible restartsKartik K. Agaram2021-11-281-1/+3
| | | | | | | | | | | | | | | | 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.
* use header everywhereKartik K. Agaram2021-11-281-3/+3
|
* unused variableKartik K. Agaram2021-11-281-1/+0
|
* standardize filenames that teliva strews on diskKartik K. Agaram2021-11-282-26/+26
| | | | | We still need a proper story for file system side effects. But it's not time yet for sandboxing considerations. Soon, but not yet.
* restore editor state from snapshotKartik K. Agaram2021-11-282-1/+62
|
* make look_up_definition more composableKartik K. Agaram2021-11-281-7/+12
|
* save a snapshot of editor state across restartsKartik K. Agaram2021-11-282-1/+14
| | | | | | | | | | | | | | | | 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.
* more salient concept of 'views'Kartik K. Agaram2021-11-281-4/+4
|
* fix backspace on MacKartik K. Agaram2021-11-282-1/+6
| | | | | I'm deliberately restricting this incompatibility to the editor environment for now.
* editor hotkeys: sol/eolKartik K. Agaram2021-11-282-4/+20
| | | | | I'm growing attached to ^e, so mildly breaking with convention there. Perhaps this is a bad idea.
* pass some CFLAGS at least to libcursesKartik K. Agaram2021-11-271-3/+3
| | | | | My Makefiles are an utter mess. Unclear how to reconcile staying close to upstream with being clean in isolation.
* .Kartik K. Agaram2021-11-271-0/+1
|
* one final issue building on Mac OS XKartik K. Agaram2021-11-271-2/+2
|
* now building on OpenBSDKartik K. Agaram2021-11-273-14/+15
| | | | Still emitting a bunch of warnings on OpenBSD, though.
* select C99 in luasecKartik K. Agaram2021-11-272-3/+3
| | | | | | I can't select C99 in luasocket, because I don't know how to include the definition of struct timespec. All this fucking complexity. But hopefully things will build on OpenBSD now.
* select C99 standardKartik K. Agaram2021-11-273-5/+10
|
* clean up luasocket build fileKartik K. Agaram2021-11-271-142/+15
| | | | | | Teliva is never intended to be "installed" somewhere. Just work inside its directory and separately share the .tlv files you create. (Though I don't yet have a good flow for starting a new .tlv file.)
* .Kartik K. Agaram2021-11-271-6/+6
|
* fix build on MacKartik K. Agaram2021-11-273-2/+7
|
* starting to test compilation on Mac and BSD.Kartik K. Agaram2021-11-271-2/+2
| | | | | | | | For starters, put Linux-specific stuff in a Linux-specific target. By not resetting MYCFLAGS and MYLDFLAGS, I'm unnecessarily passing in -DLUA_USE_LINUX. But that'll make it easier to get things running on Mac and BSD.
* bugfix: emit legal Lua representationKartik K. Agaram2021-11-261-1/+1
|
* support space/backspace in recent changes viewKartik K. Agaram2021-11-261-6/+8
|
* standardize indentKartik K. Agaram2021-11-261-4/+4
|
* colorize comments in recent changesKartik K. Agaram2021-11-261-0/+4
|
* support notes on editsKartik K. Agaram2021-11-261-2/+38
| | | | | Unlike both conventional version control and wiki history, I'm planning to always allow modifying commit messages.
* periodic cleanup of warningsKartik K. Agaram2021-11-261-3/+3
|
* .Kartik K. Agaram2021-11-261-4/+3
|
* .Kartik K. Agaram2021-11-261-1/+1
|
* don't mislead immediately after undoKartik K. Agaram2021-11-261-1/+7
|
* .Kartik K. Agaram2021-11-261-1/+0
|
* more obvious serialization of undo eventsKartik K. Agaram2021-11-261-0/+4
|
* render undo eventsKartik K. Agaram2021-11-261-0/+8
|
* start processing undo eventsKartik K. Agaram2021-11-261-0/+14
|
* start recording undo events in timelineKartik K. Agaram2021-11-261-6/+30
| | | | We're not using or rendering them yet.
* save timestamp on change; show in recent changesKartik K. Agaram2021-11-261-2/+20
|
* .Kartik K. Agaram2021-11-261-0/+1
|
* clean up traces of an old experimentKartik K. Agaram2021-11-261-2/+2
|
* add support for metadata in Teliva programsKartik K. Agaram2021-11-261-12/+26
| | | | They don't have any semantics yet. We just ignore them for now.
* undo to a specific pointKartik K. Agaram2021-11-261-4/+12
| | | | Still highly experimental. I'm not persisting state yet.
* standardize screen headingsKartik K. Agaram2021-11-261-1/+5
|
* start of 'recent changes' screenKartik K. Agaram2021-11-261-0/+102
| | | | | | | | | I'm still unclear on precisely what the experience should be here. We probably don't need all of a version control system. The goal is just to be able to answer the question, "what did I change recently that caused things to break?" For now let's just start with letting people see past versions.
* eliminate tail call using gotoKartik K. Agaram2021-11-261-1/+2
|
* clean up terminal in a specific situationKartik K. Agaram2021-11-261-7/+6
| | | | | | | | | The problem: if ever I hit ctrl-e to go to the big picture view and then hit Esc to go back to running the app, my terminal was messed up after exiting the app. Why did I even have this gunk? Perhaps it dates from the time when kilo was emitting raw escape sequences rather than using ncurses.
* dedup an enumKartik K. Agaram2021-11-263-24/+26
|
* .Kartik K. Agaram2021-11-261-2/+2
|
* .Kartik K. Agaram2021-11-261-2/+2
|