First draw of part #3 text editors

content/news/2024-07.md

@@ -67,5 +67,156 @@ Check out the amazing plug-in at https://www.rowbyte.com/blog/stipple-image-stip
 
 ## Text Editor Experimentation #3 (Skytrias)
 
-TODO
+Last month we covered the first steps of an AST based editor. We looked into the basic structure of nodes that correspond to the textual odin input, how we can build the AST manually and rendering.
+
+### First Step
+
+My first step after getting rendering working, was to build a predefined tree and have shared identifier editing work. It's nothing crazy but cool to see the effect of just using the same string source work out easily.
+
+<video class="ratio ratio-16x9 mb-1 rounded" controls src="/images/news/2024-07-skytrias1.mp4"></video>
+
+### How Editors Work
+
+Let's first remind ourselves how normal text editors work. We have a raw text file that we can edit (encodings ASCII/UTF8/etc). 
+
+1. Insertion of 1 or more bytes
+2. Remove 1 or more bytes
+3. Select multiple characters
+
+The keyboard maps onto this easily:
+1. typing in characters to create them literally
+2. backspace/delete to remove the character at the cursor or the selection
+3. shift to extend the selection
+
+Any more complex higher level features can be built on top of this like multiple cursors by keeping the basics easy.
+
+### Navigation
+
+Coming back to the AST editor there are a few questions. 
+
+1. How do we *move* around generally
+  - Move by AST Nodes
+  - Keep a textual based movement system
+  - Switch between modes or representations
+2. What really is moving "vertically" now? Before it was moving to the same X Y-1 or Y+1 position
+  - Move to the nearest AST node above/below
+  - Move to the most logical AST node to follow up on
+3. Multiselection makes sense but overcomplicates things
+  - Selecting multiple nodes is easy, but how do we *really* edit
+  - What do we allow
+  - What kind of restrictions would have to apply
+
+<figure class="figure w-100 text-center">
+  <video class="ratio ratio-16x9 mb-1 rounded" controls src="/images/news/2024-07-skytrias2.mp4"></video>
+  <figcaption class="figure-caption text-center">RED: Decl_Value | GREEN: Stmt_Assign | WHITE: Expr_Ident</figcaption>
+</figure>
+
+I opted for moving horizontally through the nodes as they were layed out. Vertical movement happens to the closest node. Also the mouse picks the layed out region of the text to pick the node. As any accessory syntax like colons, commas or equal characters are just there to understand meaning, they arent "selectable".
 
+### Editing
+
+Raw text editors don't put any constraints on the user at all. The compiler does the interpretation and sends any syntax errors back. How does an AST editor handle this and should it be language independent or not?
+
+We have to ask ourselves a few crucial questions again.
+
+1. Do we want to always create a perfect AST where we can guarantee the compiler accepts it? 
+2. Copy/Paste arbitrary nodes or only specific parts
+3. What is the undo/redo complexity
+
+How do we insert specific node structures and all their respective types? Here is a list of all possible node types we have to make editable.
+
+```odin
+Node_Type :: enum {
+  Expr_Start,
+    Expr_Ident,
+    Expr_Proc_Lit,
+    Expr_Basic_Lit,
+    Expr_Comp_Lit,
+    Expr_Unary,
+    Expr_Binary,
+    Expr_Paren,
+    Expr_Index,
+    Expr_Deref,
+    Expr_Slice,
+    Expr_Call,
+  Expr_End,
+
+  Type_Start,
+    Type_Pointer,
+    Type_Distinct,
+    Type_Array,
+    Type_Dynamic_Array,
+    Type_Proc,
+    Type_Struct,
+    Type_Union,
+    Type_Enum,
+    Type_Map,
+  Type_End,
+
+  Stmt_Start,
+    Stmt_Block,
+    Stmt_If,
+    Stmt_When,
+    Stmt_Return,
+    Stmt_Defer,
+    Stmt_For,
+    Stmt_Range,
+    Stmt_Case,
+    Stmt_Switch,
+    Stmt_Assign,
+    Stmt_Using,
+    Stmt_Bad,
+  Stmt_End,
+
+  Decl_Start,
+    Decl_Value,
+    Decl_Import,
+  Decl_End,
+
+  Field_Start,
+    Field_Basic,
+  Field_End,
+}
+```
+
+### Insertion Feels Good
+
+Here is the last record video I have. You can see scope movement, linear tree movement 
+attempts. It looks quite easy but lot's of logic had to be added to make these basics work. 
+
+On the left you can see the list of possible node types. The idea for testing was to select the one you want (almost like scratch) and insert that on "enter".
+
+I'm also showcasing moving nodes around in the parent declarion values, which again seems nice.
+
+<video class="ratio ratio-16x9 mb-1 rounded" controls src="/images/news/2024-07-skytrias3.mp4"></video>
+
+### Editing Nodes Will Feel Bad
+
+I think the hardest thing to realize is that editing a tree linearly is bad. Let's take a normal math equation example, `result := 10 + 20 - 30` where the rough tree for that would be:
+```odin
+result         :=           x + y            x - y
+          Decl_Value ':='
+Expr_Ident     ->       Expr_Binary '+'  Expr_Binary '-'
+                           10 + 20
+                Expr_Basic_Lit Expr_Basic_Lit
+                                             30 - 30
+                                (Expr_Basic_Lit) Expr_Basic_Lit
+```
+
+Those are 7 nodes that had to be "created" and correctly set instead of plainly typed out. The tree is a few levels deep for a simple declaration. Imagine it going more complex anything non trivial and representing insertion/removal/navigation becomes difficult.
+
+### Ending Notes
+
+One thing I remember when discussing this with ***GingerBill*** was that, he likes the idea but he would always wish for an "escape", where you can just type in raw text and it will convert that to the AST representation.
+
+While I like the idea I think it feels like a defeat to the whole idea of the editor. In that case you could just have a raw text editor but parse the AST all the time to get IDE like features. 
+
+I could agree with maybe a more partial version where you have AST nodes and some are just raw text like the math equation example. That would loose all meaning of shared identifiers and such though.
+
+I feel a bit beaten at this point and ended up abandoning this due to a never ending stop of complexity for virtually no benefit. Which is sort of the whole problem of inventing in this area. We can't achvieve the same original feel as a raw text editor, so why even bother.
+
+I would still love to see innovation or other examples of an AST editor, so if you see anything please let me know!
+
+### Next Month
+
+The last part will come out next month, where we'll look into a middle ground, the ***Token Based Editor***.