From c40e7259783fdb1e15ee7294785239aa41a49443 Mon Sep 17 00:00:00 2001 From: cqc Date: Sat, 6 Aug 2022 12:03:33 -0500 Subject: [PATCH] uhh --- human.ml | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/human.ml b/human.ml index 257d41c..1364e9d 100644 --- a/human.ml +++ b/human.ml @@ -13,7 +13,6 @@ a computation console - while editing a data object wille search for the previous and next `;;` or BOF/EOF and execute the enclosed text and the commit message includes the character offsets of the executed text. - executions can modify the window system creating new windows and redirecting input focus. They define their own input handling however C-g,C-g,C-g will restore the window system to the default?? - but how do we integrate this with the ocaml environment and name spaces?? some options: - always wrap execution units from data objects in some sort of local namespace so opens are not global? @@ -2304,3 +2303,19 @@ let start () = Init: setup initial panetree and compute eventree and imagetree from it.last_actions New events trigger parsing the eventree, the results of which update the imagetree which is then parsed and displayed. *) + +(* 220805: This is fundamentally trying to: + - display lines of text in a variety of ways + - allow manipulation of the display of the document + - display and manipulate history of the document + - turn the document into a tree + the + + your previous idea around the binary tree display layout is ok but is it really trying to shove documents into trees when you can't then de-encode them into a file? That seems rough... + + you have an in-memory irmin store, and you really just want to be able to navigate it + but it's going to be lots of linear things (the internet, lol), so you still need linear document navigation + but what if you can rethink linear document navigation but switching the tree structure around while still making the layout a tree (Irmin.Tree), but now the history is a tree (Irmin.History) which just encodes the state of the display. This would require an in-memory Irmin store that + + If the Irmin Tree is better implemented than the garbage i am trying to make ad hoc, (i.e. we can implement all our cursor movement and editing mechanisms with the Irmin.Tree interface easily, then yea lol) +*)