Nested parens in inline markup

Petr Kovar <pknbe at volny.cz>
Thu Feb 5 14:36:06 EST 2015

On Thu, 05 Feb 2015 18:04:36 +0000
Philip Withnall <philip at tecnocode.co.uk> wrote:

> On Thu, 2015-02-05 at 12:37 -0500, Shaun McCance wrote:
> > https://github.com/projectmallard/mallard-ducktype/issues/1
> > 
> > = Inline Test
> > Let’s put nested non-syntax brackets in an inline: $code(AddContact(ss)
> > → (u)).
> > 
> > The first ) is parsed as closing the $code(. The correct way to write
> > this right now is $code(AddContact(ss$) → (u$)), escaping the right
> > parens. I could see this being a common gotcha, because parentheses are
> > rather common. Options:
> > 
> > 1) Leave it as-is. Markup is markup, and sometimes you have to escape
> > stuff.
> > 
> > 2) Change the bracket characters to {}, which are less common in normal
> > prose (though more common in code): $code{AddContact(ss) → (u)}.
> 
> Eww, that would make things look ugly. I quite like Ducktype as it
> appears now.

Agreed. Since readability should be a key design principle for all
lightweight syntaxes, I would strongly prefer () over {}. Tech comm
people will likely find it much more convenient to use the former. 

> > 3) Let you choose between {} and () for the bracket characters. I think
> > this is unambiguous, though I'd have to write the parsing code to be
> > sure.
> 
> That would require as much input/thought from the document author as
> manually escaping the closing parens, but would be as ugly as option
> (2).
> 
> > 4) Let you optionally double up parens to avoid escaping:
> > $code((AddContact(ss) → (u$))). Oops, still doesn't help when the
> > non-markup right paren is at the end. Also, if your content begins with
> > a left paren, you'll have to escape that to avoid the parser thinking
> > you've done double parens.
> 
> Also requires as much thought as options (2) and (3) and, as you say, is
> flaky.

+1
 
> > 5) Keep track of non-markup parens so that $code(AddContact(ss) → (u))
> > actually works. I don't know if any other format does this. Seems simple
> > on the surface, but it could get hairy. Imagine a situation where you're
> > putting markup around unbalanced expressions:
> > WRONG:   $em(()parenthesized text where the parens are italic$em())
> > WITH #1: $em(()parenthesized text where the parens are italic$em($))
> > WITH #5: $em($()parenthesized text where the parens are italic$em($))
> 
> My vote would be for this, since it would lead to the most natural
> markup in common situations. One thing we could do is only enable it for
> some inline elements which we expect to typically require it. e.g.
> Assume balanced bracketing within $code() and $cmd() elements, but not
> within $em() or $link() (for example).

If we can have it enabled only for some elements, that would be nice.

My 2 cents,
pk