Related: http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs http://tratt.net/laurie/blog/entries/an_editor_for_composed_... (posted a few days

Related: http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs http://tratt.net/laurie/blog/entries/an_editor_for_composed_... (posted a few days ago here: https://news.ycombinator.com/item?id=8201707 https://news.ycombinator.com/item?id=8201707). There's a link inside to their paper on Language Boxes, which formalize the whole idea. It uses an incremental parser where nodes of the syntax tree can be opaque "boxes" which could contain any other nested AST, as the languages are parsed separately. It does a nice job of tackling the syntax composition problems, of which the proposals seem like a special case. As Tratt points out though, the ideas are not particularly novel - they've been around for decades, but are usually met with resistance as they break existing workflows or programmer expectations. The design philosophy behind Eco, their prototype editor for language boxes, is that it should look and behave almost exactly like a traditional text editor. It does support highlighting of inner languages when they're selected, but the highlighting is usually not visible. I'm pretty sure we could turn them always on and get the kind of appearance this post is looking for.