Hi! I am the author. I will be glad to answer any questions.<p>First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity. I talk more about it in the article in the <i>Project's Philosophy/Homogeneity</i> section in [1] The Power of Structure.<p>I am proposing we need to really start considering a different paradigm, and attempting to do it right, and that's structural editing. People are wondering if it's possible to be writing better structural editors. We all know there have been attempts to do those, and, well, lo and behold, those were janky too.<p><i>But they don't have to be.</i> When people start thinking of structure-editing, they immediately jump to the "how do we do C++".
Well, in fact, I could tell you how we could do exactly that: you could start small. You start with what you know. And you know that you could, say, start with structuralizing the {} brackets. That's a semantic unit. So, that's a start. Even without getting down to the compiler level.<p>But I am not arguing I am about to do wonders for something as complex as some mainstream langauge in terms of a structural editing. I believe it can certainly be attempted, though, and certainly improved, peacemeal. And what you can't do: mix it with the traditional string-based editing. Or take python: that one would structuralize pretty nicely by indentation. Would it accomplish everything? No. But it would certainly help.<p>The gist of it boils down to the fact that you don't need to start at that very complex level, you can do things piecemeal and still get many benefits. Ask yourself this: can you edit a /list/ structurally, i.e. edit like in a string-based editor while maintaning an actual list behind the scenes? Sure, you can. A tree? Absolutely. Look at Paredit.<p>THERE'S NO REASON FOR THAT TO BE JANKY. NO reason why that wouldn't work.<p>It can absolutely be done.<p>And, really, structural editing like I am proposing /subsumes/ string-based editing, because you can just write a specialized editor for general strings, and use that for things you don't know how to structure yet. And yet, even those string-based editors can be specialized further, as some semantic units like words, expressions and even characters are often immediately apparent.<p>What does that give us? At the very least: object identity and programmatic access, and having the ability to pick your own data structure.<p>This kind of small things are what's actually going to be very useful for stuff like note-takers and computational notebooks and REPLs and what not. We don't need to start with programming languages (though I am going to do a Common Lisp IDE).<p>Please, ask me anything! Let's talk!<p>PS Another very important point is that ambiguity can be localized. Look at the Alchemy section in [1] where I discuss dealing with the reader (but I also talk about it in <i>Rune</i>).<p>PPS And thank you for posting this. It's exciting to be reading comments. Truly.<p>[1] <a href="https://project-mage.org/the-power-of-structure" rel="nofollow">https://project-mage.org/the-power-of-structure</a>