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.
I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.