I haven’t delved too deeply into the capabilities of the syntax highlighting engine in Atom, so forgive me if some of this is already in there just not well-taken-advantage-of by the current syntax packages. But as one of my recent posts stated, I wanted to share some of my more radical thoughts on what a truly awesome editor should be.
As @codinghorror et al have stated in the past, more and more often we are encountering languages within languages. Regular expressions is one of the more oft-cited examples, but even JavaDoc or YARD documentation markup in comments can be used as a reference:
# Frobs the frobnicator. # # @return [Bar] New frobnicator setting. def foo # snip end
What I would like to see here is not for one package to have to handle every possible sub-language that is embeddable in the super-language, but for one package to handle the super-language (in the text above, Ruby) and another package to handle the sub-language (in the text above, YARD). Having this kind of composability of syntaxes (syntices?) would significantly raise the capabilities of the editor without raising the bar of complexity for language syntax package authors.
Also, I would hope if I wrote a Foo syntax package that it could automatically and easily compose with any language that supports Foo embedded within it. Both SQL and regular expressions come to mind as something that is often embedded in other languages. (Well, and everything is embedded within HTML these days.) So if I was writing the Ruby syntax package, I could tag a sequence as a regular expression and be confident that sequence would be highlighted by the user’s choice of regex highlighting package.
We all understand what composability does for us in our applications. Let’s afford it to ourselves in our syntax highlighter so that we don’t get frustrated that embedded SQL is highlighted differently in Foo language as opposed to Bar language because the person who implemented the Bar highlighter knows more about SQL than the Foo implementer.