I've been toying with the idea of making something very very much lik this, but, for an existing language. Which makes it far, far more complicated; I'm sure various aspects of the design of whatever language one would build this for are needlessly convoluted due to not having been designed with this kind of editing in mind.<p>A few concerns:<p>* As developers, our 'world' is so defined by text, we textify things that aren't: We write marked up documentation in plain text (HTML, markdown, etc) and we despise using tools like LibreOffice to write that sort of thing, and we even 'draw' helpful graphs in `.dot` files. We do this for a good reason: It 'works' with our other tools. git itself, and the cavalcade of git-understanding frontend version control systems, are excellent at showing you diffs between textual representations. They don't do 'diffs between these 2 png files' or 'diffs between these two .docx files' well or at all.<p>Hence, these projects either balloon, or need a pragmatic take. Either you staple 'also reinvent git' onto the project (and in passing you are increasing the hurdle to adopt or try out this stuff for any interested folk), or you think about how to adapt the idea to fit existing practices.<p>In this specific case the latter seems like the obvious answer: The way to store the program is as a file that, if opened in a text editor, looks just like it. But, I _can_ edit files in git and it looks like a text file even if it really isn't; so what happens if I edit an eyg file with a text editor? How 'perfect' must it be? What happens if in hand-editing the file I added some whitespace that shouldn't have been there as per the canonical storage rule?<p>These are all easily solvable details, of course. But it's where my brain went. I'm pretty sure the correct answer is 'the source file is still text and is still readable; it's just that the language has some extreme style requirements (think about a language that has no line continuation facilities whatsoever, long lines will just have to be long lines, and dictates exactly how many tabs you can insert; indenting with spaces is not allowed at all, that sort of thing). This is fine because the language is meant to be read as plain text but only edited with the structural editor.<p>* I often try to think how it would be if I was doing my programming work with a structural editor. From time to time I do things that seem blatantly annoying if I only had a structural editor. Where I really _want_ to dip into syntactically utterly invalid gobbledygook because I'm doing some text edits which will get back to valid code but I go through invalid code. For example, block-based copy/pasting (block = multiselect/multicursor). I'm having a hard time seeing how that would work in a structural editor but I use it from time to time. It feels like a structural editor can hopefully come up with alternatives for all the use cases but I'm not sure. Should there instead be a 'fallback' option where your source file turns into raw text mode and your edit functionality is like any plain jane text editor, you do your text-based transformations and then when done exit that mode, at which point the structural editor reparses what you have. I think that's right but it means the language does, actually, need all the bells and whistles after all: A Parser, an AST, good error handling for syntax errors, and so forth.