4 ms·

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'

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

thaumaturgy 14y ago
I've just finished writing a hyperlink parser; getting it to handle your specific case would be totally do-able. I think your overall point still stands -- there would be ambiguous edge cases -- but if Reddit comments are anything to go by, they really wouldn't be any worse than the current confusion, and making ()[] interchangeable would clear up a lot of the common problems that users have with making links.
- AngryParsley 14y ago
  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.
  - thaumaturgy 14y ago
    1. URL parsing is a solved problem. Since I so frequently have my competence questioned on HN, I have to conclude that if I can do it, anyone can. 2. There are a number of people in this thread, and many many many more on Reddit and on other forums that use markdown, that have had a specific UX problem with markdown which we can solve. The solution will not solve all possible problems, but it will solve many of them. 3. I subscribe to the Linus Torvalds camp of software development, which is that software exists to solve user problems. 4. While the trade-off between additional code complexity (and better overall user experience) versus simpler code (and poorer overall user experience) isn't always justified, in this case I think it is. I mean, HN parses URLs for you and makes them clickable -- would you really support removing that as a feature, in favor of having simpler code, and having to copy & paste links into your browser? 5. This particular feature rather nicely lends itself to extensive testing so that you can make sure you've covered most of your edge cases. If we decide not to implement solved, testable features out of fear that some other programmer might not implement it correctly or test it thoroughly enough, then I don't know what to say about our industry other than that it's going to come to a standstill. I'm afraid that's all the energy I have tonight for arguing about things I don't really have any influence over on HN.

thaumaturgy 14y ago

I've just finished writing a hyperlink parser; getting it to handle your specific case would be totally do-able. I think your overall point still stands -- there would be ambiguous edge cases -- but if Reddit comments are anything to go by, they really wouldn't be any worse than the current confusion, and making ()[] interchangeable would clear up a lot of the common problems that users have with making links.

AngryParsley 14y ago
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.
- thaumaturgy 14y ago
  1. URL parsing is a solved problem. Since I so frequently have my competence questioned on HN, I have to conclude that if I can do it, anyone can. 2. There are a number of people in this thread, and many many many more on Reddit and on other forums that use markdown, that have had a specific UX problem with markdown which we can solve. The solution will not solve all possible problems, but it will solve many of them. 3. I subscribe to the Linus Torvalds camp of software development, which is that software exists to solve user problems. 4. While the trade-off between additional code complexity (and better overall user experience) versus simpler code (and poorer overall user experience) isn't always justified, in this case I think it is. I mean, HN parses URLs for you and makes them clickable -- would you really support removing that as a feature, in favor of having simpler code, and having to copy & paste links into your browser? 5. This particular feature rather nicely lends itself to extensive testing so that you can make sure you've covered most of your edge cases. If we decide not to implement solved, testable features out of fear that some other programmer might not implement it correctly or test it thoroughly enough, then I don't know what to say about our industry other than that it's going to come to a standstill. I'm afraid that's all the energy I have tonight for arguing about things I don't really have any influence over on HN.