Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigating that. Also he has a 5 year plan to prove this all.
Still deciding if I buy it. only wants 1000 bucks a month to work on it full time, I think exploring the area is worth that at least.
I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost.
I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.
Seems like the argument is in the "Rune" part even more down below. I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that. The point on ambiguity localization is kind of curious too.
I don't think there's an argument to be had for all structures, just that you can do it for each custom structure, and that's the point.
Maybe the editors of the old tried to bite off too much when they attempted embedded structures, and they didn't have the right abstractions in place. If you look at https://tylr.fun it shows that things that weren't being done back then, there are interesting approaches now.
> I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that.
Emacs modes, in other words?
Like how, in Emacs, C-n nearly always does "move to next line" but it could mean "highlight next mail message" and "Enter" nearly always does something with the current line but it could mean "open currently highlighted message" or "newline and indent as per language-specific rules" or "send this line to a subprocess" or whatever.
Modes don't do embedding. Try having a fully-seperate mode for a comment section in your code. Try to do that contextually, too.
Modes don't do that. Neither do they let you control the underlying structure, they give you no ability to treat structures as objects. Yes, they do provide a common interface, but that's where the pros end. Ofc its emacs, and there are projects like Multi-Major-Modes that at least try to subdivide a document into editable areas... speaking of ridiculously slow.
Hey, I just wrote a general reply on structure editing here in this thread, please do check it out. Also, I have added a notice in the article to skip the Fern section, as it's, indeed, probably best left for last, in case you are interested in the platform as a whole. I should have really done that before.
As for constraints and prototype OO: I think those will simply do great for GUI building, and for flexibility. I think you need such abstractions to be able to deal with customization and complexity of embedded structures. I am basing Fern on the Garnet GUI framework [1], which had ~80 projects and was pretty fun to use judging by what people say.
So this is another take on the whole "text as a structure"-idea, where there are so many failed projects already? Hasn't emacs even some packages around this?
Article written by someone who experienced Emacs as being slow and janky. Yet Emacs is one of the fastest software I use. Now I am definitely an Emacs power user: I started using the native-compilation branch as soon as it came out, I don't mind building from the source the latest version available when I see something that picks my interest, I've got about 3 000 lines of custom elisp code, I'll be using other really fast stuff, like burntsushi's amazing ripgrep, directly from Emacs, fzf too, etc.
I don't understand the criticism about Cider: I use it daily.
Emacs 29 with libjansson and native-compilation is plenty fast.
And most of all: apparently every single new version of Emacs not only runs but also compiles faster. And this is coupled with my computers which only gets faster too.
At the moment I'm running Emacs 29 on a AMD 3700X, soon to be replaced with a 7700 or 7700X. That's going to be yet another performance gain.
Most software only get slower and slower with each release (I was already using IntelliJ IDEA back when it was a version 4 and already bloated, since then it's been downhill perf-wise): Emacs, on the contrary, always keeps getting faster.
And the goodies added to Emacs lately are just insane: native-compilation, LSP support, tree-sitter (it's just been included in Emacs and it should bring yet another round of crazy speedups)...
