7 ms·

I'd also advocate for accepting reversed ()[]'s on links. In other words, let the user type: [something](http://whatever.com) or (something)[http://

by raldi 14y ago

I'd also advocate for accepting reversed ()[]'s on links. In other words, let the user type: [something](http://whatever.com) or (something)[http://whatever.com] ...and have both work exactly the same. It will save a lot of trouble -- and especially when linking to a Wikipedia page whose URL contains parentheses.

cryptoz 14y ago
I've been annoyed by that on reddit for...like 6 years. "You can just escape it" people say. As if normal reddit users are gonna escape strings themselves these days.
- raldi 14y ago
  I once wrote a piece of software for my own use that used Markdown, and I wrote a thin preparsing layer that would allow it to do the right thing regardless of which of these I typed: [http://foo.com][text] [http://foo.com](text) (http://foo.com)[text] (http://foo.com)(text) [text][http://foo.com] (text)[http://foo.com] [text](http://foo.com) (text)(http://foo.com) I think it might even have accepted {}'s.
mmahemoff 14y ago
Something this flexible for images would go down nicely too.
AngryParsley 14y ago
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.
olalonde 14y ago
Or why not simplify the syntax by using the same delimiter for both text and URL: [something][http://whatever.com] As far as I know, this should be mostly backwards-compatible with current Markdown.
- lloeki 14y ago
  because [][] is used for [reference-style links][daringfireball.com], which allows you to write stuff like I did and still have []() handle both URIs, absolute paths or relative paths. All of those debates about the link syntax is a complete and ridiculous bikeshed. Any solution I read around here above about making it "smarter", "better", or whatever just end up in making it awfully and needlessly more complex and ambiguous, and yet another bikeshedded standard. The way it is currently is totally KISS: [x](y) => link (i.e a href) and [x][k] + [k]: z => resolve k then link to z. Escaping ')' is trivially solved by the second case. [daringfireball.com]: http://daringfireball.net/projects/markdown/syntax#link http://daringfireball.net/projects/markdown/syntax#link
SiVal 14y ago
Why not _click here_ [http://whatever.com http://whatever.com] as a more natural way to do it? The underscores imply underlined text, which has traditionally meant inline link, followed by a single, square-bracketed chunk that is obviously the URL? (I'm not saying here that the resulting link anchor text has to be underlined, just that this pseudo-underlining serves as a mnemonic for writers and readers of the raw markup.)

by raldi 14y ago

cryptoz 14y ago

I've been annoyed by that on reddit for...like 6 years. "You can just escape it" people say. As if normal reddit users are gonna escape strings themselves these days.

raldi 14y ago
I once wrote a piece of software for my own use that used Markdown, and I wrote a thin preparsing layer that would allow it to do the right thing regardless of which of these I typed: [http://foo.com][text] [http://foo.com](text) (http://foo.com)[text] (http://foo.com)(text) [text][http://foo.com] (text)[http://foo.com] [text](http://foo.com) (text)(http://foo.com) I think it might even have accepted {}'s.

mmahemoff 14y ago

Something this flexible for images would go down nicely too.

AngryParsley 14y ago

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.

olalonde 14y ago

Or why not simplify the syntax by using the same delimiter for both text and URL: [something][http://whatever.com] As far as I know, this should be mostly backwards-compatible with current Markdown.

lloeki 14y ago
because [][] is used for [reference-style links][daringfireball.com], which allows you to write stuff like I did and still have []() handle both URIs, absolute paths or relative paths. All of those debates about the link syntax is a complete and ridiculous bikeshed. Any solution I read around here above about making it "smarter", "better", or whatever just end up in making it awfully and needlessly more complex and ambiguous, and yet another bikeshedded standard. The way it is currently is totally KISS: [x](y) => link (i.e a href) and [x][k] + [k]: z => resolve k then link to z. Escaping ')' is trivially solved by the second case. [daringfireball.com]: http://daringfireball.net/projects/markdown/syntax#link http://daringfireball.net/projects/markdown/syntax#link

SiVal 14y ago

Why not _click here_ [http://whatever.com http://whatever.com] as a more natural way to do it? The underscores imply underlined text, which has traditionally meant inline link, followed by a single, square-bracketed chunk that is obviously the URL? (I'm not saying here that the resulting link anchor text has to be underlined, just that this pseudo-underlining serves as a mnemonic for writers and readers of the raw markup.)