every time I see such a project show up I'm both happy and sad: happy to see one more soul arrive at the "there must be something better than text" thought and doing something about it; sad because they invariably create a visual/structural editor.
... and not a really good one, at that. Not to pick on this specific one, but if you're creating a UI for code editing that's not text, please design your interaction well. And yes, I know that this is probably version 0.1 and you plan to smoothen the rough edges, which is why i'll not pick on the fact that the editor for each structural element is not even in-place, for example.
but that's not my point. writing code as text conflates two things (or 4, depending on how you think of duals):
1. source text has both syntax and meaning.
2. source text is both the display and storage format (this is the killer feature/bug).
my point is that every attempt to "solve" the "problem of coding using text" (on in this case the subset of lisp's umpteen parens getting in the way of understanding) focuses on the first half of #1 above.
as others have mentioned, there have been structural editors since the 80s. from the research i did (admittedly with limited acm access) they seemed to have died down due to two problems:
1. the scale problem: text packs the largest amount of information into the smallest amount of space. any visual/structural system better have a good way of dealing with large codebases.
2. the fluid use problem: it looks good, but is it easy to use when editing anything but a small enough piece of code this way? typically the amount of interaction "work" you have to do to jump between elements and so forth makes it very inefficient compared to text. the commonly cited example was "How do you change a for loop to a while?". in any text editor, you can take the characters apart easily to reform them into some other construct, but in a structural editor, you have to actually delete all or most of the old structure and re-form the new one. i did find research that refuted this specific claim (ask if interested), but that didn't help the adoption.
i have been thinking of "better ways to code" and structural editors in particular for about 3 years now and here're some of my conclusions to date:
1. text is king because of its universality - think cypher from the matrix saying "I don't even see the code. All I see is blonde, brunette, red-head"
2. We already have good structural editors. They're called vim and emacs. vim has the better interaction model, imo, while emacs has better support for creating new language modes (again, imho, no flame war intended). then there's the smalltalk ides that inspired the Visual Age products that inspired eclipse.
3. The additional overload of "chrome" in text the {}'s, ()'s and begin/ends are much less a hassle than that caused by a visual editor's chrome.
4. There is much more value in pursuing better ways of coding than just flogging the "text sucks" meme. Think Non-textual language workbenches, for example.
Finally, one specific commment about playing around with lisp's syntax. I've tried it (https://github.com/vinodkd/lispdown) and the one thing that stands out is: Lisp has no syntax, so it can become any syntax. I dont know how any structural editor can handle that in a meaningful way.