

SkrivML: A lightweight markup language - rhythmvs
http://markup.skriv.org/

======
fernly
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.

[1] [http://carl-sandburg.com/chicago.htm](http://carl-
sandburg.com/chicago.htm)

[2] [http://www.shakespeare-
online.com/plays/macbeth_3_1.html](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!

~~~
sriku
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.

[1] [http://docs.racket-lang.org/scribble/](http://docs.racket-
lang.org/scribble/)

~~~
fernly
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.

Now... if there was a Pandoc reader for it...

~~~
sriku
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 -

    
    
        @animal[bowow "meow"]{Various sounds animals make}
    

translates to

    
    
        (animal bowow "meow" "Various sounds animals make")
    

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.)

------
norswap
Criticism:

\- 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 :)

Otherwise quite nice!

~~~
pandatigox
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

~~~
JasonFruit
If I read it right, you're actually _disagreeing_.

------
coderdude
I like how images are written:

{{/path/to/img.png}} vs. Markdown's ![](/path/to/img.png)

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.

I like this.

~~~
ilaksh
Can we just make a new version of Markdown that supports that and Skriv |
[http://skriv.org](http://skriv.org) for links?

~~~
coderdude
Skrivdown? :)

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.

------
rhythmvs
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.)

¹ [http://blog.codinghorror.com/the-future-of-
markdown/](http://blog.codinghorror.com/the-future-of-markdown/) ²
[https://github.com/rhythmus/markdown-
resources](https://github.com/rhythmus/markdown-resources) ³
[http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-
not...](http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-
favourite-language/) ⁴ [https://medium.com/the-future-of-
publishing/495ccfe24a52](https://medium.com/the-future-of-
publishing/495ccfe24a52) ⁵
[http://johnmacfarlane.net/babelmark2/faq.html#what-are-
some-...](http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-big-
questions-that-the-markdown-spec-does-not-answer) ⁶
[http://fountain.io](http://fountain.io) ⁷ SkrivML ⁸
[https://github.com/jakwings/strictdown](https://github.com/jakwings/strictdown)
⁹ [http://www.z-m-l.com](http://www.z-m-l.com) ¹⁰
[https://github.com/rhythmus/markdown-
resources/blob/master/l...](https://github.com/rhythmus/markdown-
resources/blob/master/lightweightMarkupSyntaxComparison.tsv)

~~~
maxerickson
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.

~~~
rhythmvs
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.

¹ [http://www.aaronsw.com/weblog/001189](http://www.aaronsw.com/weblog/001189)

~~~
maxerickson
He is acknowledged here:

[http://daringfireball.net/projects/markdown/](http://daringfireball.net/projects/markdown/)

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.

------
demetrius
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.

~~~
gfv
Doesn't Russian use angular quotes or double quotes where angular ones are not
available?

------
ultimatedelman
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.

EDIT: I do like the link syntax, though.

~~~
orclev
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/](http://xkcd.com/927/)

~~~
handyman5
Is it sad that I recognized the comic from the context and the number in the
link?

~~~
boomlinde
Sad but not very surprising:
[https://hn.algolia.com/?q=http%3A%2F%2Fxkcd.com%2F927#!/comm...](https://hn.algolia.com/?q=http%3A%2F%2Fxkcd.com%2F927#!/comment/forever/0/http%3A%2F%2Fxkcd.com%2F927)

------
thegeomaster
It looks nice, but do we _really_ need another one of these?

~~~
NaNaN
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.

~~~
akurtzhs
What problems do Chinese writers run into when using Markdown or
reStructuredText?

~~~
NaNaN
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.

------
paulyg
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.

------
userbinator
_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.

~~~
fernly
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.

Not to worry, reST doesn't do it either.

------
MarcScott
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.

~~~
fernly
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.

------
smilekzs
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).

------
vim-guru
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

------
bohwaz
There's also an alternative lightweight implementation:
[http://bohwaz.net/p/SkrivLite-a-lightweight-
implementation-o...](http://bohwaz.net/p/SkrivLite-a-lightweight-
implementation-of-SkrivML)

------
OliverD
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.

------
naranja
Oh no! Please not _another_ lightweight markup language.

This increased diversity will only push Markdown's dominance and not help to
get better alternatives _at all!_

~~~
NaNaN
That is not just for Markdown at all, and Markdown is not good for everyone at
all. Why so serious?

------
estebanrules
I like the syntax. However, how many markup/markdown languages do we need?

