I've been comparing these things (ascii markups) lately, mainly because I'm writing software to support an organization with a long history using not one, not two, but three unique ascii markup conventions. Could these somehow be translated into a more or less standard one, and gain the freedom of output provided by e.g. Pandoc?
What's depressing to me -- and my depression is not alleviated by reading Skriv's syntax -- is how similar they are and yet how none of them deal with the many kinds of typographical formatting that are routine in printed books.
For one simple example: Poetry. (Case in point: [1]) People who publish poetry expect as a matter of course to control their line-breaks and their indention in support of their meaning, and to center lines of text. Only AsciiDoc ("verse" block) and Skriv support literal line breaks (outside of monospaced code blocks). I don't know of any of the ascii markups that support centered text, or controlled indents.
Another simple example: Drama, play scripts. (e.g., [2]). Act and Scene titles are centered; character names are often small-cap (try commanding small-cap in any ascii markup); in older published plays it is common to have entrances and exits right-aligned: "[Exeunt" in the right margin. Both verse and drama (not to mention legal documents) often have reference line-numbers in the right margin, on the same line as left-justified text.
Quoted correspondence often has dates and signatures right-aligned. AsciiDoc supports right-alignment only in the single case of the citation of a block quote. I don't know any other text markup that allows even that much.
In short, the couple of dozen extant markups are solving the same limited range of problems over and over for no better reason than general NIH, while ignoring the much wider gamut of published formatting.
You nailed it! I am a typographer by profession, and I know exactly what you mean. The trouble with most light-markup languages is indeed their very limited document model and set of node types — basically an html subset, just good enough for blog posts, and, at best, source code documentation.
I’d rather take inspiration from something like the Chicago Manual of Style: we need many types of lists; more levels of headings/sections and control over their formatting; plates and figures; there are many types of “blockquotes”, etc. Poetry and drama are just some of the more difficult cases. How far must one go, or what, for example, should we do with things like Apollinaire’s [calligrames](http://en.wikipedia.org/wiki/Calligrammes)?
As for your use cases: Besides AsciiDoc’s “verse” and Skriv’s support for literal line breaks, z.m.l. too takes these into account. For drama, there is Fountain.io’s domain-specific light-markup for screenwriting.
I believe that's because it's a table semantically. I mean, look at it - three columns, fixed width, sometimes columns 1 and 2 merge together. That's a table any way you look at it.
I never understood people's fear of tables - they're awesome, they're easy to control the lay out of, browsers support them just fine, they can be as flexible as you want.
And if you feel sick every time when you type a <table> tag, you can specify them in CSS nowadays.
I think you misunderstand the goal of light markup languages like that. If you're interested in typography, you'd probably convert the markup to LaTeX. If you're interested in poetry or drama, you'd probably also convert to latex and use its packages. E.g. the (now dead) deplate converter works this way to allow markup of drama/scripts (e.g. http://deplate.sourceforge.net/Input.html#hd006005) etc.
IMHO the main problem is that markdown, which serves its purpose well but isn't well thought out as a markup language because of too many ambiguities, dominates the "market".
I quite like the generality of scribble syntax [1]. It is in the spirit of LaTeX, but is programmable in racket/scheme. The downside is that it is implemented pretty much for the purpose of writing racket documentation, with little/no support for other programming languages or output formats.
Thanks for the pointer. I find the documentation pretty resistant to a quick lookover, read "The Scribble Syntax at a Glance" and be afraid.
However I see that it does support centered text, intentional line breaks and -- unique among LMLs to my knowledge -- right-aligned text spans ("margin-note" command) which could be used for poetry line numbers, stage directions, and sidenotes.
The thing is a scribble doc is not markup. It is code. (This is one of the beautiful things about lisp.) So if you want the "syntax", all you need to know is this -
The rest are just libraries of code that render these resultant data structures in various ways. When writing documents, this programmability is very powerful.
If you don't need too much programmability, but would occasionally like to have it, "org mode" on emacs is fantastic. (I wrote my Ph.D. thesis in org mode and I also use it to track tasks.)
- I dislike the fact that line returns are kept inside paragraph. I use automatic linewrapping in my text editor to produce neat markdown files that look clean both when rendered and when viewed raw.
- I would like to have the option of displaying vanilla smileys :)
I don't understand the point of it, either. Poems and the like could easily be handled by a special mode, similar to code blocks. Are there other situations where forced newlines would be useful? There may be, but I can't think of any.
Either way, severely restricting how text – source code – can be organized just to simplify some rare special cases seems like a bad idea. It's a shame, since the rest of it looks really nice.
I agree with you on the line returns. It really annoys me when it's not rendered like a WYSIWYG. Especially when I'm quoting or writing something like a poem.
Nevertheless, I quite like how CSS classes fit nicely into the syntax
{{/path/to/img.png}} vs. Markdown's 
List syntax is nice and reminds me of wiki syntax. I've always favored that style over Markdown's list syntax. Actually a lot of it reminds of wiki syntax. Tables also looks like a breeze to remember how to write.
You'd have to switch to Skriv's syntax for headers since Markdown's headers and Skriv's ordered lists use the same syntax. Another thing I'd change about Markdown would be to remove multiple syntaxes for writing the same element. For example, with Markdown you can use *, -, or + to create unordered lists. That might exist for some reason I don't know about but I don't like it.
I hate '' for italic. It is strange from semantic point of view (I definitely don’t agree with the "its syntax is intuitive" claim), and it would force me to change the keyboard when I’m writing in Russian.
This seems like a more verbose version of Markdown :\ Maybe the only advantage is displaying code, but everything else is either equal to or more verbose than Markdown.
Yeah, that was basically my reaction as well. They tweaked Markdown a bit, changed a few things around, but it's pretty much identical to Markdown. I don't really see any big wins here. This XKCD seems somewhat appropriate: http://xkcd.com/927/
You should be happy that it is not named Yet Another Markdown Language. And I don't think there will be a standard Markdown in front of the people who shout out HOLY MARKDOWN until John Gruber release an update.
"Verbose" seems to be a trade-off for removal of intrinsic ambiguity (and the resulting standard wars) within markdown, which I speculate as the reason we still haven't come up with one "standard markdown" despite many calling for it.
IMHO this took minimal yet established markups from various wiki and markdown-ish syntaxes, further simplified them, finally approaching what we wanted as a "standard markdown" in the first place.
Better than just seeing Markdown/reStructuredText/AsciiDoc/Textile/... there. I'm designing a new markup language, too. Happy to draw inspiration from Skriv.
Not all markup languages are good for blogging, especially for different spoken languages. At least, both Markdown and reStructuredText are not very good for Chinese writings.
Most inline markups require spaces surrounding the text, and Chinese do not need spaces between words. Although reST provide "\ " to remove the spaces from output, it makes the document ugly.
I jump between Creole and Markdown and this seems like an interesting mashup. Though I don't like all the choices made. I have been thinking lately about just combining Creole and Markdown into one master markup lang.
The one thing I really like in Skriv is the ability to assign CSS classes to paragraphs or divs. That is something I have wanted in an abbreviated form for a while. I wrote an extension to do this in my own Creole parser but most of the time I am using someone else's or writing in Markdown so I can't use the syntax.
These markups can affect full-words only, they are not effective if they are written in the middle of a word.
What if you want to emphasise parts of a word? I know I've had to do that at least a few times. This seems like one of those things that felt like a good idea and does work most of the time, but then really infuriates you when you find out that it's virtually impossible to do it.
As in documenting an API or command syntax, when you want to go from mono (literal) to italic (variable input) with no break. In Skriv it would be ##--input=##''filename'' except that (a) Skriv requires a space and even if it didn't, (b) the -- would be an unbalanced strikeout code.
I've yet to find any markup language that has the power and flexibility of org-mode.
It makes for exceptionally tidy source files, with neat folding of headers. Tables are a breeze. You can easily run the code in your code blocks. Adding css styling is a piece of cake.
All this an only a couple of hundred key combinations to memorise.
Thanks for pointing out YALML (lightweight markup language) for my collection! With regard to my comment below, I note that Org does support a Centered mode for paragraphs and a Verse mode in which line breaks are preserved, although it does not appear to allow control of the indention of those lines.
Despite the negative tone here, I feel like the direction they're working towards.
One possible pitfall in syntax, though: two dashes within one sentence would be translated to strikeouts -- which I could only come up with context-sensitive fixes -- which would violate the core principle (of removing ambiguity).
Why make yet another markup language without any real improvements to the widely adopted markdown? Curly-braces are usually used to bind data, so you actually loose a great advantage that markdown has with it's syntax. Let's improve markdown instead
I would change ''italic'' to italic. It is easier to remember how to create a bold and an italic word if you only have to remember one sign. Besides the ' sign is not very common in some countries.
Happy to read there is some interest in “Markdown 2.0” or “lightweight markup, next generation”. With adoption by big outlets like Github and StackOverflow, and dozens of static site generators built on plain text source files, marked-up in Markdown syntax, Markdown is becoming a _de facto_ general-purpose document _editing_ and _storage_ standard. With the advent of fast client-side parsers, soon it might even substitute html as a document _exchange format_, too (at least for some use cases).
But there is no official spec, development of the syntax grew stale (from the start, thanks to Gruber)¹, and hence the language heavily suffers from fragmentation²: people want to be able to do more with light-markup, so they build extensions, or fork the language altogether. The troubles with Markdown are discussed in various³ places⁴, John MacFarlane built a formalized comparison tool⁵, but as of yet, there is no joint effort to cooperate on a lightweight markup standard.
There are a few interesting projects that dare to forsake Markdown and try their luck: Fountain.io⁶ (a domain specific light markup language for playwriting), SkrivML⁷, Strictdown⁸, and z.m.l.⁹
Then there are, of course, the many predecessors of Markdown, which prove that Markdown (or light-markup in general) is not the imprescriptible privilege of its self-proclaimed benevolent dictator for life, and some of which are still widely used in various communities: Setext (1992), AFT (1999), Grutatxt (2000), AsciiDoc (2002), MediaWiki (2002), reStructuredText (2002), Org-mode (2003), Textile (2004)…
We need an extensible lightweight markup language of sorts, a “lxml”, if you will, and we need to work on it together.
If we want ever to succeed in establishing a true standard light markup language, the big challenge is not only to focus on extensibility, but also to reconcile the various existing and future syntaxes, and take care of backward-compatibility (with plain Markdown), as much as possible. As mentioned by quite a few commenters here and elsewhere, weeding out conflicting syntax should be the first thing to do.
For starters, I begun a concordance¹⁰, listing the various delimiters and patterns used by competing lightweight markup languages. (Very rough draft, though, and need to think about a way to formalize the data, to make more accurate comparisons, and consequently, better decisions on the syntax of a future xlml.)
The intransigence that Gruber gets so much flack for is largely limited to asking people that make a text processor incompatible with Markdown to not use the name.
I haven't researched carefully to figure out if he coined the word, but if he did his request is pretty reasonable.
Fair enough. But then again too bad Gruber gets all the credit (and consequently the privilege of nomenclature), while the late prodigy Aaron Swartz at least was his underacknowledged co-inventor.¹ I don’t think Swartz would have agreed on such a lock-in.
You have to scroll down to the heading that says "Acknowledgements".
Setting aside that your statement is not especially precise, the style of your argument here is pretty gross. If you want to find something a dead person actually said on a matter that is one thing; arguing that they surely would have agreed with your position is quite another.
What's depressing to me -- and my depression is not alleviated by reading Skriv's syntax -- is how similar they are and yet how none of them deal with the many kinds of typographical formatting that are routine in printed books.
For one simple example: Poetry. (Case in point: [1]) People who publish poetry expect as a matter of course to control their line-breaks and their indention in support of their meaning, and to center lines of text. Only AsciiDoc ("verse" block) and Skriv support literal line breaks (outside of monospaced code blocks). I don't know of any of the ascii markups that support centered text, or controlled indents.
Another simple example: Drama, play scripts. (e.g., [2]). Act and Scene titles are centered; character names are often small-cap (try commanding small-cap in any ascii markup); in older published plays it is common to have entrances and exits right-aligned: "[Exeunt" in the right margin. Both verse and drama (not to mention legal documents) often have reference line-numbers in the right margin, on the same line as left-justified text.
Quoted correspondence often has dates and signatures right-aligned. AsciiDoc supports right-alignment only in the single case of the citation of a block quote. I don't know any other text markup that allows even that much.
In short, the couple of dozen extant markups are solving the same limited range of problems over and over for no better reason than general NIH, while ignoring the much wider gamut of published formatting.
[1] http://carl-sandburg.com/chicago.htm
[2] http://www.shakespeare-online.com/plays/macbeth_3_1.html and this is a wretchedly ugly example but look at the source! It's a TABLE!