Ducktype inline markup

On Tue, 2014-11-18 at 14:13 -0500, Shaun McCance wrote:
> Time to talk about inline syntax. This is what happens inside paragraphs
> and other blocks. We have some requirements:
> 
> * We need to actually specify element names, because we're going for
> full semantics.
> * We need to be able to specify both attributes and content.
> * We need to be able to specify attributes with empty content.
> * We need to be able to specify content without attributes.
> * Do we need to be able to specify empty content with no attributes? Not
> for anything in the core, but best not to lock out extensions.
> * We need to be able to nest inline markup.
> * It needs to be unambiguous with other Ducktype syntax.
> 
> Here was my original proposal (where ">" is shorthand for "xref=").
> Please provide input. Even input like "that looks ugly" is valuable. I
> want minimal ugliness.
> 
> 1) To hide a file, &link[>files-rename](rename it) with a &key(.)
>   at the beginning of its name.

Right now, I'm leaning towards $ as an inline marker, so:

  To hide a file, $link[>files-rename](rename it) with a $key(.)
  at the beginning of its name.

The inline marker would also be used for entity references, so you could
write things like $eacute; or the hex $00e9; to get an "é". We can also
make it possible to define entities at the top of the file. Because of
this $ appeals to me because it looks like a variable reference from
shell or perl or the like.

We'd also use the same marker for escaping special characters. Want to
start a like with a "["? Use "$[". Same for "*", "-", "@", "=", and "$"
itself. This gives another advantage over using "&". With "&" as the
inline marker, whenever you write code in a language where "&&" means
something (that's a lot of languages), you'll have to escape it as
"&&&&", and that's just annoying. Using "$$" is relatively rare.

Parser implements this right now. Check out the inline*.duck files here:

https://gitorious.org/projectmallard/duck/source/tests

--
Shaun