AngryParsley

vor 14 Jahrendiscuss

To fix the ambiguous grammar, we need to add a url parser to markdown? This is a perfect example of how changes that seem simple to humans can have enormous impacts on software complexity. As you said, introducing that complexity wouldn't help in many cases:

  Blah blah blah (side note)[1](#ref_1).
  Blah blah blah (side note)[1](ref_1.html).

I don't mean to be hostile, but just because something is "doable" doesn't mean it should go in the spec. Adding things to a standard imposes costs that feature-proposers rarely consider. It forces programmers to write more code to support that feature. More code means more bugs. These bugs annoy users and cost valuable programmer time. Multiply these costs by the number of times the standard is implemented and you can easily end up with millions in lost value.

Vanilla markdown doesn't require a url parser. It doesn't have ambiguous grammar. It's small. It's simple. And that's a good thing, because markdown parsers have enough bugs in them already.

AngryParsley

vor 14 Jahrendiscuss

I feel your pain. Parens in links made me never forget %28 and %29. But I think your solution causes more problems than it solves. The biggest issue is that it's not backwards-compatible with current markdown. For example, in a citation following parentheses:

  Blah blah blah (side note)[1](http://url1).

Your markdown generator could output

  <a href="1">side note</a>(http://url1).

  (side note)<a href="http://url1>1</a>.

The latter is current behavior, but your suggestion makes the grammar ambiguous. Most parsers are "greedy", so the former is more likely to be output. Unless you specified more complex behavior, people would have to go back and escape their parens near links.

comments