Thank you for your feedback!
I have identified some issues I’m currently struggeling with, mainly with introducing strong node IDs. I’ve read a bit about other approaches, from elm-UI to elm-css and working with generated UUID, for example here: Enforcing unique ID
I haven’t had time to really think all the alternatives through, but I haven’t really found a way I like in order to have strong IDs and thus features like “node references”.
Another issue I have is that, in my approach, the central type is a Node a, so that each node in a tree must feature the same data type. This makes it impossible to mix languages, as far as I can imagine it. One way I tried was to just get rid of the unbound type a, and say everything is just a Node, but this loses even more type safety in Elm, since I would have to work with strings or something similar primitive to “tag” nodes and distinguish them at runtime. I currently opt for keeping the “typed nodes”, losing the ability to mix trees.
I’ve a modelling background, so if you want to you could point me to some model examples or describe your modeling use case here and I can try and see if I could map it to my current prototype somehow. The “challenge” with modeling with text is that text is unstructured by itself, so one needs to have some sort of parsing in place, which is exactly what the idea of a structured editor avoids.
I’m currently also started to look into tree-sitter a bit to see if I could laverage it to nicely play with strucutral editing. Cause with incremental parsing and a concrete syntax tree that is “always live”, text editing all of the sudden becomes very similar to structural editing.