Along with the many disruptive trends in code editors and text documents (Markdown) in general (Markup) comes the inevitable question, Is it time for a new take on the various design patterns and implementation strategies used to work with source text?
Code Editors
While there are many JavaScript code editor implementations out there, you can almost divide them down by eras, for instance, ones predating GitHub's overwhelming effect on the adoption of Markdown, ones during the height of JQuery… etc. But regardless of eras, the way those editors model markup, while very much full of a lot of originality and creativity, they often seem to pivot around variants of similar and familiar patterns. One clear observation that begs pointing out, since most (if not all) value features in any implementation are often coupled to the specific variations of the markup model, adopting new and distruptive ideas often times leads to completely new implementations (some still call those versions).
Markdown
Markdown, though not the origin of this following sentiment, managed to breakdown the cognitive divide that separated plain text from rich formatting. It too comes with many implementations (sorry flavours), most with ingeneious WYTIWYG notations, aside from the clever concepts that eventually prove more blunt to implement than a spec-complient DOMParser. But unlike HTML's almost infinite planes of flow, all of the Markdown out there has mainly three planes to conceptualize with
- Inlines — to be:
<img>,<b>,<a>,<code>… etc. - Blocks — to be:
<p>,<ul>,<table>… etc. - Fenced Block — to be:
<figure>,<iframe>… etc.
AST
Abstract syntax trees, do to markup what DOM does to formatting. Those are guilty of the fact that they can only be reasoned with to approximately the same extent as those who contrive them, be it the illogical, the simple but brilliant, or the common savants who like us struggle to see things from a perspective unlike their own. The bottomline is that ASTs if used, must be used right, all around, otherwise like we see in reality, bumbling with ASTs is at the very least wasteful and irresponsible. Still, to their credit, even with all the uncheck ugly that AST-based solutions often take to handle shortsight and other contradictions, they allowed as to do so much more with text than Regular Expressions and any document state abstractions which often relying on borrowed structures found in more linear interpreter designs.