I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and made different tradeoffs along the way. For example, this is why I find myself using "print" debugging on a process of 10^4 values. It is fun to think that, "maybe I can step debug this" on that many values, but... that is well beyond my capability to keep it in my…
I just, can't imagine what benefit you get from opening an X gigabyte file. Maybe I don't fully understand the context, but... why shouldn't you open a big file? I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit. I have a similar problem with my current editor of choice. I used to have a "raw"…
In that case, it was the fact that adding a bullet point to a list would rescan the whole list (so it could simply update a bullet count in the header). You would need to implement incremental parsing for that, and that's not very easy. And certainly not natural.
> If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming.
Absolutely, that's one of the points.
I must add something, though. It's not just about speed. And, in fact, it's not even just about editing.
Most exciting possibilities of the structural approach stem from the fact that you can start thinking in terms of objects: then you write textual interfaces for those objects, for the purposes of textual (or even graphical) interaction.
The bare-bones example is that if you had a table, or a tree in a note-taking application, then you could query that tree, but you would still retain the textual interface. Even better: you could embed any editor within any other editor, which would directly correspond to a compound structure at hand.
To give you an idea of a note in a KR (knowledge-representation, prototype OO) system:
(create-schema power-of-structure
(:is-a kr-note)
(:title "The Power of Structure")
(:tags '("seamlessly-structural editing" "power"))
(:introduction '("Welcome to Project Mage!"
"The purpose of this article is [...]"))
(:table-of-contents nil)
(:sections (create-schema))
(:related-links nil)
(:footnotes nil))
Now, all you would have to do is lens that object, aka, construct a tree of embedded editors for it (which Rune will also do via KR, just like the object above).
Another example: code. A large comment block? View and edit it via a note-take application, or a markdown application, or what have you.
Another example (leaving some details aside): attach comments to any piece of code (up to a character). That comment doesn't even have to be a part of the editing workflow. I think that's pretty powerful (and there are more use cases, see Alchemy in [1]).
[1] This example is directly from https://project-mage.org/the-power-of-structure