This seems portable to emacs-lisp judging from the ClojureScript that is powering the Atom plugin and the .cljc running the site. An existing alternative for Emacs is mastery of paredit and use of aggressive-indent-mode.
I think this is nicer for newbies than getting the three-key chords required for good paredit use ingrained in muscle memory. I think it’s wonderful that the lisp indentation conventions benefit improve developer productivity, not just code readability.
EDIT: Added link to the site’s source.
And alternative syntaxes (Lisps without parens) have faltered since they sacrifice some of Lisp’s power that seasoned users aren’t willing to part with.
The syntax sweet-expressions does not sacrifice any of Lisp’s power. I’m surprised at this inaccuracy, since the authors even mentioned sweet-expressions in the Acknowledgements section. Sweet-expressions have indeed faltered, but not because they lack homoiconicity or the other benefits of Lisp syntax.
I think these are the reasons for sweet-expressions’ unpopularity compared to editor tools like Paredit:
The build problem at least in Common Lisp with the typical build setup (ASDF, possibly with Quicklisp) seems like it should be solvable. I’m not a Lisp reader or packaging guru, but if you write a package in sweet-expressions, shouldn’t it be possible to set up ASDF so it’s loadable as a regular Lisp package without the user needing to know the difference? It seems like the package should be able to handle that internally, loading the sweet-expressions readtables as a dependency. Of course, to modify the package’s source, other people would need to buy into sweet-expressions (learn how to read/write them, get their editors set up appropriately, etc.), but users who just want to build and use the package should be able to ignore it.
Really would like this for Emacs, also, such good documentation in both form and content.
This looks game changing. Might be worth switching to Atom for, at least temporarily.
Wowza. Eagerly awaiting the LightTable plugin!