Here's hoping they can finally work natural _underline_ support in...
Edit: I've wondered whether the original Markdown didn't have underline support because <u> was deprecated/removed from HTML. FWIW, <u> is now back in HTML5.
Underlines traditionally have semantically meant the same as italics. When an editor wanted the printer to make a certain word italic, he would underline it in the draft.
Really, underlines are a useless decoration. That's why HTML took them out. Not sure why they put them back in...
Like you said, they are a decoration. When handwriting something, some people use underlines for different kinds of emphasis. Those people want to make text look a certain way. It's good that HTML5 brought back underlines, just in case someone wants to use them, they at least have the option.
The primary reason is to provide for Chinese proper name marks (where underlining has a semantic meaning) and occasionally for misspellings (in English, we'd probably add the editorial text [sic]). As a decoration, it is useless, but there are circumstances where it has semantic meaning. (The <b> and <i> tags were promoted back to respectability for the same reasons, since using <em> for text that is not stressed or <strong> for text that would traditionally be bolded without implying extra importance is just as semantically incorrect as using <i> and <b> for stress and importance would be. Arbitrary spans don't imply any semantic meaning. Where I would have used <span class="foreign" lang="fr"> previously, I'd now use <i class="foreign" lang="fr">. The <i> tag marks the text as special rather than just arbitrarily styled.)
If you've ever been involved in producing content management systems for non-technical users (typically involving TinyMCE/CKEditor etc etc) then you'll probably welcome this as much as I do.
Dodgy HTML, content pasted in from Word (with crazy styling intact), and a general encouragement for users to see text content in terms of styling rather than structure are all things that it will be delightful to see the end of.
It'd be nice if it Markdown was added to HN, at least for a consistent way of quoting that's better than using the code tag (which frequently cuts off text for some reason in mobile Safari).
> (which frequently cuts off text for some reason in mobile Safari).
Is this just because it doesn't wrap, and mobile safari doesn't display a scrollbar? (I've never used mobile safari, but I think that's true of the Android browser.)
Quoting with code blocks can be awful, but > is fine even if it's not explicitly formatted.
> Is this just because it doesn't wrap, and mobile safari doesn't display a scrollbar?
Pretty sure that's it. OS X (Safari and Chrome, at least) does the same thing unless you have a mouse plugged in. The formatting is such that it doesn't feel like it should scroll, even in the common case of characters being cut in half. Better styling on code blocks would do wonders for this.
I'm not that psyched about automatic return-based linebreaks. Everyone thinks they should use linebreaks to align their text, and the system should just ignore all single line breaks.
The current behavior of Markdown solves this problem very well. I don't want the newlines I enter for non-wrapping editors to remain in the generated HTML.
I agree, I am having trouble thinking of a situation where specific line break positions would be important to me in regular text that isn't covered by some other markdown structure such as code blocks or lists.
One word: poetry. Traditional break behaviour (new para) is great between stanzas/verses; not so much between lines. (It's also the primary reason why the <br> tag still exists in HTML.)
It's not a matter of there being no work-around. MarkDown is meant to be as much for ease-of-use for the content creator/editor as it is to be a readable alternative text source. And HTML isn't always the desired output, so why should users have to know anything about HTML unless they're creating HTML?
That hidden feature is so thoroughly buried that I didn't even know about it until I read your msg - and I've been writing markdown for years. For mainstream users, it might as well not exist.
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.
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:
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.
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.
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:
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.
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.
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.
Why not _click here_ [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.)
This would completely defeat one of the best parts of markdown, which is the ability to mix in HTML tags whenever you want, when you need to represent something more complex.
I might be the only one, but I actually prefer Markdowns handling of a single "enter" without spaces at the end to mean that the paragraph is not finished. It makes writing blogs and various other stuff in Vim much simpler, and I can more easily reformat text to wrap at 80 characters, and have better control over it.
Could I soft-wrap in my editor? Sure, but that would mean that the text files sitting on my hard drive now have very long strings in them making it harder to grep, making it harder to add to git (change a single character, entire line is now a diff :-().
No, I didn't, but thanks! That's very useful. Additionally, google + the help command led me to :help text-objects, which describes a lot more goodies similar to 'ip'.
If this is a change that Jeff really wants, he needs to fork Markdown. This change actively subverts one of the goals that Gruber set down for Markdown, which is that Normal People can use it.
Changing this, especially for people who implement Markdown parsers, is geek arrogance.
The biggest deployments of Markdown — StackOverflow & GitHub — do not squash line breaks. They made this decision because authors did not assume their line breaks would be discarded.
The change is not geek arrogance. It is, in fact, a reaction to how Normal People use it.
If you think that users of StackOverflow and GitHub are “Normal People”, you need to adjust your personal RDF.
My wife is not a geek or a programmer. She will, if forced, learn the intricacies of an idiotic programmer‘s decision to make something easier for him (and it’s almost invariably a him) in order to participate in a particular forum. This is why people put up with crap like bbcode every single day. That doesn’t mean she enjoys it.
Markdown works because it makes plain text readable and formatted nicely. Markdown works because it works just as well in a plain text email as it does in an HTML-formatted email.
It doesn’t work because some geek says that the people who use heavily geek-oriented sites (StackOverflow & GitHub, to use your examples) are in fact ”Normal People”. (And, just for what it’s worth, I do find the fact that I have to join all my hard-wrapped lines back together in SO & GH comments to be immensely annoying. At least their markdown parser for .markdown files doesn’t do this.)
So, no I am not flat-out wrong. I hear geek whining that parsing is made harder because of a design feature that is present because most people don't think about or want to think about “correct” line-endings.
Before you decide that I’m full of hot air, understand that I am working with my wife’s novel that’s written in Markdown so that I can parse it (possibly using an existing well-written-and-maintained parser like peg-markdown or peg-multimarkdown as an intermediate mechanism) and then transform it into the LaTeX formatting required for making her PDF output and the HTML formatting required for making her EPUB (and thus MOBI) output.
I am well aware of how ugly some of it is…but it makes it easier for her to write her novel without falling back to proprietary formats like .docx. I’m willing to deal with some pain as an implementor in order to minimize what she has to deal with.
As such, I don’t really have a lot of patience for this type of geek whinging.
Why do you feel like normal people, who have been trained for decades--not just on computers but on typewriters as well--that hitting enter means "go to the next line", would have an easier time if that assumption was violated? You even see the formatting in front of you: you are now on the next line, and yet when rendered this information is somehow ignored and the text is pasted together. E-mail clients, which have been doing crazy things to our text for years, don't even do this: the closest they come is format=flowed, and that's a special set of rules designed to be generated by clients, not typed by mere mortals.
I feel this way because of the reality that many people will centre text in a document by inserting spaces in front of the text they want centered, rather than using their word processor's centre command. It drives me absolutely bonkers to see that, but it's reality.
I feel this way because of the reality that many people will hit enter two dozen times to go to a new page, or to position a bit of text.
In the time that I've been working with computers, what I've come to realize is that most people simply don't have a grasp of the abstractions of the computer—they remember particular incantations that worked for them last time and keep doing them again and again.
My wife is an intelligent person; probably smarter than I am. She speaks three languages and has taught for the last twenty-two years. Watching her use the computer drives me absolutely bonkers because she doesn't use any of the things that I know make the computer easier to use. Neither does her sister. Why? Because neither of them have time to specialize in the use of the computer. They use it a lot, and I've been able to introduce a few things—but only for things that simplify their lives because they integrate into how they already work.
If two of the most intelligent people I know don't have a lot of these expectations…why do people think that most people would expect things to work the way that Jeff has proposed?
In a sibling comment (I only want to reply once), stickfigure says:
“Normal People have a consistent expectation regarding the behavior of line breaks.”
Actually, I don't think that Normal People have any understanding of line breaks at all. They understand letters, words, sentences, paragraphs, and to a degree pages. They know they want something to show up on the page, but they have no understanding of how the computer does its magic to make that happen.
stickfigure: “Normal People are comfortable with markdown in the first place. Neither you nor your wife are Normal People.”
For the second sentence, I agree and disagree. I'm certainly a geek with a more-than-passing interest in layout, formatting, fonts, etc.… This stuff interests me in a way that most people and most geeks certainly would never be interested in it. My wife is also not normal people on some level—she’s married to a geek who can take care of things like this for her. At the same time, she is 100% a computer user and has no interest in learning to program or learning to fight with programs that actively get in her way.
She also doesn't know Markdown as such. She knows a tiny subset that I have introduced to her that provides her with exactly enough to write her novel and for me to format it the way she wants it. (That's the paragraph rules, italics, and headings.) I've shown her a few other things for when she blogs—but even when she's using the Squarespace WYSIWYG editor, I often have to go in and edit the links to make them right.
There's a lot more that I could show her, but she neither has the time nor the interest to learn it.
Both of your examples--using spaces to center text and using a dozen newlines to position text--are based on the reasonable assumption of "what I see in my text is what I got when I formatted it": removing carriage returns entirely and pasting lines together to form larger lines violates that assumption. If the user expects that they can go to the second page by adding a dozen newlines, how could they possibly understand that newlines now don't mean anything at all? I will repeat: for decades, the enter key has meant a very specific behavior, and Markdown is the only setup I can come up with that either myself or my mother (or my grandmother) would have ever come across where the enter key doesn't cause at least a single line break.
Most people think that a block of text that is set together is a paragraph, especially as block paragraph format has become the norm for casual and business writing; indented paragraphs are the exception used when you have a layout process and not just depending on your word processor to get it right for you.
Email and HTML have not helped this; it is a common expectation that a blank line between two blocks of text represents the paragraph break—at least based on the emails that I've seen over the last two decades.
A fundamental philosophy of Markdown is that a Markdown document looks reasonable when sent via email as text or when sent as a formatted web page. That it's flexible enough to be usable for more than just email and HTML is a bonus.
It is also a common expectation that if you put a newline in an e-mail message, even without a blank line intervening, that the person who receives the message will not get the two lines pasted together to form a single line. The problem with the newline behavior of markdown--and to a very real extent this is the only such feature of markdown that has this bug--is that the text you are looking at looks nothing like the text that ends up being rendered.
I'd respectfully submit that if your wife is writing a novel with actual line break characters at the end of each visual line, rather than only at the end of paragraphs, she's kind of an edge case. "Normal people" who have been using word processors since the late 70s have had it drilled into their head that you only hit return at the end of a paragraph.
It's my suspicion that Markdown was written the way it was solely to handle the case of blockquotes having ">" characters at the start of each line, and the reason that mattered is because BBEdit and Mailsmith had commands to wrap text that way, chiefly for quoting mail messages. This happens to fit in very nicely with the way Vim and Emacs wrap paragraphs, and I know there are people who've written novels in both. But I assure you that the vast majority of fiction writers are used to word processors, and for that matter, so are the vast majority of users typing things into text boxes. And if those users wrote a little poem
That had lines
Which looked like this
And failed to rhyme
Because they weren't really poets
...the chances are they would just hit return at the end of every line, because that is the way every program they have used in their entire lives works. This is why GitHub and StackOverflow made that change: because Markdown is not like HTML to most people. It's like plain text. In plain text, when you press return it means "end of paragraph." The way Markdown does it -- and the way Hacker News does it, I just discovered! -- violates the principle of least surprise. I am not writing HTML, I am writing text, and I expect it to act like text.
(For what it's worth, I've written a collection of short stories in Markdown and created the EPUB from that using my own Python scripts to do so. I am an edge case. Anyone who is writing fiction in a text editor instead of a word processor is also an edge case. Sorry, but it's the truth.)
If you are throwing away the ability to have visually formatted source text, all the teeth gnashing over the name of the new, properly standardized and beautifully implemented format becomes completely ridiculous. Nice looking source text is pretty much the core principle of markdown.
Which I suppose is the source of Gruber's apparent obstinance, if someone wants to make changes that exchange his design principles for other design principles (I don't think he cares much about naive users), why should he hand them the name of his project?
(to clarify, "apparent obstinance" is me doing a poor job of keeping sarcasm out of my post, I don't have a problem with Gruber insisting that the markdown name is his)
I agree -- but it doesn't seem to me that "treat return characters as hard line breaks" equates to "throwing away the ability to have visually formatted source text," unless one is using an editor that is unable to deal with soft-wrapped text gracefully.
Stackoverflow requires you to add two spaces to the end of every one of those sentences in your poem to work as you just said it did ... Stackoverflow DID NOT make that change you suggested it did.
* people typing markdown in text files, where you want to split paragraphs into word-wrapped lines of a sensible length, and consecutive non-blank lines form paragraphs just as they always have in text files;
* and people typing markdown into text entry boxes on web pages, where you would like pressing the <enter> key to actually mean something.
These two situations probably prefer a different default.
Then make the form that the user enters data into be either parsed differently, by pre-processing it, or have some javascript magic that automatically adds the extra two spaces required to make it work.
This way if the user presses <Enter><Enter> then the JS can remove the extra two spaces and it will still be valid markdown.
I think this behavior is the better route because it accommodates both crowds. The line-wrap folks can just press enter twice; no biggie. But the console and vim users of the world can continue using line-breaks the way that work best for their environment.
On the flip side, making a single enter start a new paragraph wouldn't really help the GUI users (what's the difference between one line break and two, really?) but it would really hurt the console users of the world
I, too, would be strongly against "automatic return-based linebreaks." Given that markdown has constructions for lists and code blocks, one very rarely needs a hard line break anyway. Currently markdown works fine both for people who hard-wrap and people who soft-wrap. Let's keep it that way.
I convinced my team to use pandoc instead of Word for documenting a new project, and now, because creating tables is so hard (they are not like Emacs users), I'm considering lobbying them back to Word, or writing a preprocessor to insert tables from CSV files... feels bad man.
How can this be harder than creating table with Word? Word always gets in the way. Word appears to be easier but down the road, it always end up as a painful process.
For me just the benefit of being mergable and delegating styling at the end of the tool chain is just plain great.
Well, add a last row with the first column larger than the previous rows, assume people don't know about column-mode editing, and you can imagine what they are doing to align...
I think I'll just "preprocess" the file, looking for something like !csvtable(filename.csv).
Wrote the script (it worked), but some specific complex features from Word still were missed ("how do I do a reference to a picture?") and couldn't be easily supported by pandoc or this script.
Though for a brief time of going full-mode procrastinator and writing another markup language...
Then I had to admit the whole thing wasn't really working and now recommend we move back to Microsoft Word because it's easier.
A day of Total fail, and procrastination, and making everyone install MikTex, pandoc and Python.
I hope I don't regret for suggesting we use Git...
As a non-web developer I cry every time I need to use HTML: It's really "ugly" in some way (And I'm used to ugly languages).
But I have learned to love Markdown too, I hope in the future, distant future: Someone will create a language that integrates HTML and CSS into a nice Markdown-like language.
<!doctype html>
<meta charset=utf-8>
<title>Hello, world</title>
<h1>Hello, world</h1>
<p>This is a paragraph about HTML.
<ul>
<li>Bullet point
<li>Bullet point
</ul>
I found that I've moved on to reStructuredText. It doesn't seem to be marketed as much as Markdown (the only reason I know about it is because of Sphinx) but I feel that it's a bit more capable. Simple tables are exceptionally easy and it handles URLs with parens in it just fine (a common pain when trying to link to Wikipedia articles with Markdown).
I use rst for everything due to using Sphinx heavily. Trivial tables are easy in any markup, but non-trivial ones are a pain. I use table mode in emacs, but we can't require everyone to use emacs.
I hate its URL handling.
And of course it needed Sphinx to make it work across more than one source file which means we now have two dialects.
I do wish everyone would just agree on one syntax and be done with it.
Have you tried using the list-table directive? I find it's a much easier way to create tables - it's based on writing indented lists which mirror the logical structure of the table (i.e., table / row / cell), rather than trying to produce ASCII art.
All my doc is in Sphinx so I play it safe, and all directives need to be supported in whatever version of docutils and rst2pdf are installed across the various developer machines. So for the moment I am stuck with ascii art.
Regarding the URL handling, I also used to hate it, but wrote a tool to make it easier to deal with; details are here if you're interested (despite the title, the relevant tool is not Vim-only): <http://tadhg.com/wp/2012/10/07/tools-for-writing-restructure...;
The bit I hate is that I have no desire to have a global list of URLs and manage them. So instead I have to put a double underscore suffix after every url otherwise you get bizarre error messages. eg `foo <foo.com>`__
rst is definitely better than markdown.
Honestly I also prefer textile to markdown.
And I sorta believe wikicreole is better than markdown.
I cannot understand for what reason MD has become popular, it has an annoying and confusing syntax for half of the things, supports many less things than others and is not stricly better in any way I can think of.
Supporting many less things is markdown's big advantage. It's a format that makes everything as simple as possible, but no simpler; it's the perfect format for "almost-plain" text like I often want in a readme - mostly plain text, but with headings, bulleted lists and the occasional hyperlink.
Compared to rst it's a lot easier to write links. I hadn't even heard of textile, but its link syntax also seems harder to write than markdown's. WikiCreole might be better, but right now figuring out what syntax a given wiki will support is far more of a crapshoot than using an arbitrary markdown implementation.
I'm using reST for everything: docs for people (converting them to html and doc before sending), doc-comments in every language I use, be python, T-SQL, java or F#
I love Markdown, and, this is an awesome effort! I'm working on a Markdown editor/platform that could really benefit if this sort of stuff wasn't so fragmented: http://www.nimblenot.es/ (yes, that was a shameless plug)
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions
Which is appealing to me, and many others I suspect.
I manage a large forum and we use BBCode. I recently "open sourced" our rules (https://github.com/minecraftforum/rules) and during building the system you see there I made the decision to opt to use Markdown over BBCode -- what everyone that uses the forum is used to.
BBCode isn't inherently "bad" if you're just writing something and won't ever edit it again but for anything that you will need to edit / review in the future it can be a serious pain in the ass to look through.
These are the two examples I used:
### Title here
This is some text [with a url](http://google.com)
vs.
[size=6][font=arial, helvetica, sans-serif]Title here[/font][/size]
This is some text [url="http://google.com"]with a url[/url]
BBCode was written to be written, it's no more difficult to write
[url=http://google.com]google[/url]
than it is to write:
[google](http://google.com)
but when reading the source (for maintaining) it... sucks, because it feels un-natural. With the Markdown version of linking (to pick a basic example) you can read a sentence how the person reading the processed version would read it:
A search engine called [google](http://google.com)
That reads as "A search engine called google" and then you see that google is a hyperlink. With BBCode it would read:
A search engine called [url=http://google.com]google[/url]
So first you read "A search engine called" then you see it's a URL and then you see "google". It can get very frustrating when you're looking at huge swathes of text written in a similar style.
John Gruber's original Markdown.pl is one of the worst small programs I have ever read, completely riddled with outright bugs and misfeatures that continually bite its users in the ass. It's awful even by the already low standards of hand-written many-pass regex-based spaghetti-parsers.
Nobody should be using the original script, and unfortunately many of the other implementations out there are direct transliterations that replicate all of its absurd errors, like where if you mention the MD5 hash of another token in the document, the hash will be replaced with the token, because it uses that as an inline escaping mechanism! Reddit got hit with a XSS virus that got through their filters because of it: http://blog.reddit.com/2009/09/we-had-some-bugs-and-it-hurt-...
See the changelog for what started as a PHP transliteration and turned into a rewrite that squashed 125 (!) unacknowledged bugs: http://michelf.com/projects/php-markdown/
The worst part is that he outright refuses to either disclaim or fix his implementation, and so far he's repudiated everyone else's attempts to do so. He's a terrible programmer and a worse maintainer, he really still thinks the documentation on his site is comprehensive and canonical. As much as Jeff Atwood leaps at every chance to play the fool, there's no way his directorship can be anything but an improvement.
This would be a lot stronger argument without the ad hominem bits. He's obviously not so terrible if he created this thing that has people so up in arms.
I think there's something to your post, but the tone makes me want to dismiss it. I know, stupid emotions.
This internet lynch mob mentality... I wonder how much this discourages people from releasing things. So, Gruber releases markdown.pl. People like it. People love it. People use it, people reuse it, people rewrite it. Next think you know, he's being insulted on the internet because he released something he wrote to serve his needs and not passing on some sort of figurative mantle or blessing.
The perceived simplicity of the format (driven by the naivete of the implementation) played a significant role in making it popular, but lays a minefield of bugs and ambiguities for implementors especially if they want any combination of sanity and interoperability.
> He's obviously not so terrible if he created this thing that has people so up in arms.
Oh please, double standards like this disgust me. Microsoft had shit slung at it for years on end by the tech community because IE was terrible and held back innovation on the web, but no one claimed that IE is "not so terrible" just because everyone cared about it.
The difference with Gruber is that he's a darling of the tech community because he's Apple-anointed nobility. But as a programmer, in my eyes (and in the eyes of any other objective observers) he's absolute shit.
No, the difference is that Gruber is a person whereas Microsoft is a corporation. Corporations aren't subject to the same social mores - it isn't hurtful to say something nasty about a corporation.
Abandoning basic etiquette that you should have learned in primary school and calling someone "absolute shit" is not cool.
While I agree that calling somebody that is not cool, I think you'll find that product owners at corporations do take it to heart when harsh criticisms are called out. They identify with their output.
The reason Microsoft is dead to many developers (myself included) is that they used their massive corporate power to shut down good startups making cool stuff.
I didn't care that IE was terrible (until v3 or whenever), I cared that Microsoft went to all the major PC manufacturers and told them that their licensing deals were toast if they preloaded Netscape.
I didn't care that Word was a crappy word processor, I cared that they used their market position on office documents to make minor incompatibilities that prevented WordPerfect from interoperating.
I didn't care that Windows file sharing wasn't half as good as NFS, I care that they continually fucked with the SMB protocol so that no one could sell UNIX machines that could share with Windows networks.
It has been an absolute pleasure watching that Microsoft's power over device makers disappear. The world is better off for it, and Microsoft will always be an asshole in my book.
There's a differenc between trying to maintain app store policies that strike a balance between security, end user interests, developer interests, profitability, etc. and intentionally putting bugs in your OS to break third party products, stealing third party products and building them into your OS, or bundling free products with your platform or office suite to drive third parties out of a market.
The thing is this isn't something new, I and a number of other people have been enraged by this for eight years now.
Over those years it's grown in usage exponentially, and so has his fame as a sportswriter for team Apple. Throughout that period he's continued to brush off all kinds of attempts to clean up bugs, define ambiguous behavior, or fix the security vulnerabilities. It hasn't mattered what approach people have taken, he just does not give a shit. Here's an example from last week: http://six.pairlist.net/pipermail/markdown-discuss/2012-Octo...
He's spent so long burning off any goodwill I would have for him on the matter, being cordial just isn't a priority anymore. NERD RAGE.
You've been enraged by the handling of a text-to-HTML converting Perl script written by a tech writer?
You're right: he just does not give a shit. I can see why. What possible upside could there be to engaging with someone who handles themselves like you are here?
You've never been enraged by poorly written tools or technologies? There have been times I wished I could reach through my monitor and throttle some well-meaning idiot for wasting hours or days of my time.
Imagine that you're a mechanic working on a motor that uses the ProprietaryNew fastener (hex heads? so 20th century!). Unfortunately, the only ProprietaryNew wrenches are made out of cheap metal, and the sockets strip with regularity. You can't imagine saying a few nasty words about the parentage of everyone in ProprietaryNewCo?
Actually I think he does give a shit, he just feels that things could be a lot worse than they are and tinkering isn't necessarily going to improve things. Given how widely used it is there is some merit to this argument.
From a comment on Twitter yesterday in response to someone, it doesn't seem that Gruber is particularly interested in engaging with this (though I may be wrong). If that is the case I suspect we'll see a forking of the project and we'll get to see whether a committee will do better.
It may well do - Jeff has a good track record at getting things done and is well respected and well liked - but personally I wouldn't put my mortgage on it because as well intentioned as these things are we all know how design by committee usually turns out.
Care to show us your alternative? It'll be on Github or GoogleCode, or maybe your personal blog, somewhere we can download it, try it out, and criticize it too, right?
Surely 8 years of rage is enough encouragement to write your own replacement for ~1000 odd lines of Perl?
Or by "enraged", did you mean "annoyed enough to write critical posts on random internet sites, but not motivated enough to spend an evening or two solving the problem myself"?
"The real problem cannot be solved without some forward action on his part."
Sure it can - you write something better, then get everybody who's already using Gruber's version or one of it's presumably also-flawed reimplementations to switch to yours. Or, is "8 years of enragement" really just keyboard-warrior-hyperbole on your part and an excuse to criticize someone who's achieved widespread adoption of some code you claim is 2nd rate, but which haven't bothered to improve or replace?
Besides, it sounds to me like David Greenspan has come up with a fine solution.
I find it disheartening that the top voted comment is so blatantly rude. I'm not sure what is gained by calling John Gruber a terrible programmer and maintainer. If you want to praise Jeff Atwood for taking over the stewardship of Markdown, great.
Christ, maybe I should pull all my open source projects that I no longer work on down from github for fear of people actually using it and then complaining when I don't maintain it indefinitely.
The dude released a script to the public under a free software license and people used it. If you think it's bad, fork it and fix it, otherwise don't use it, that's how the open source ecosystem works.
I thunk the point he's trying to make is that if Gruber doesn't want to maintain Markdown, that's cool. However, he should announce that and let the community take over.
Yes, you should take down such projects if you have been informed of problems and can't or won't take the time to document them. Infinite maintenance is a straw man, because that wasn't requested. Only some civility was requested.
Your project can cost people a lot of time if it promises, but doesn't deliver. I just spent quite some time searching for a decent XSD parser in Ruby, haveing to wade through a score of projects that promise to do what I want, but turn out to be incomplete, buggy or otherwise useless to me. Many people will perform the same quest and together a lot of time is wasted, which could have been prevented if people would not just publish any damned thing, but would also take the time to properly document its state.
Open source projects without proper documentation, I can do without. This problem will only become worse in decades to come. I sure as hell hope github will start purging old projects with too many 'not useful' votes within the next few years. Otherwise it'll be a morass of stink where the gems can no longer be found.
There are a dozen MarkDown implementations that are better than Grubber's piece of shit, and a couple that are actually nice. The lack of a decent implementation is not the issue. This issue is that Gruber is (regrettably but naturally) seen as the authority on MarkDown by a whole lot of people, and he's still encouraging them to use his insecure, bug-ridden disaster instead of pointing them in the direction of something that anybody outside of his use case would ever want to use.
He just needs to add a sentence or two to his website and he'll save countless developers a ton of headache. He just doesn't give a shit.
What an embarrassing post to be occupying the top of this thread. Blaming Markdown.pl for security flaws? I suppose the memory corruption bugs in the "optimized" C Markdown parsers are somehow his fault too?
He wrote a text-to-HTML parser with a particularly elegant little language design and got on with his life, which involves writing more than keeping up with bug reports in Perl scripts. Get over yourself; comments like this make us all look bad.
> And he did a horrible job of it. Horrible. But he considers himself the BDFL of Markdown. Break that down for me.
Christ, you're being a dick. All John Gruber did to you was design a minimalist markup language and write a quick-and-dirty proof-of-concept Perl script to implement it. Just use a better implementation and get on with your day.
If that was all he did, it would be fine. But it isn't. His website still encourages people to use his script and his specification, even though they are known to be buggy. If you publish something on the internet and it turns out be wrong or defective, you have a moral obligation to point that out, especially if better alternatives are available.
Is it insane to try and keep the good stuff from disappearing under the garbage? Have you ever searched for something, only to come across a multitude of pages that were just incomplete, wrong or otherwise useless? A search term for which the gems are buried under so much manure you need all your Google-fu to find the gem? How do you think this will play out in the years to come?
People like Gruber, with an audience, a following, should set an example. If his code has bugs and he is informed of those bugs, he should take a few minutes to list those bugs. He doesn't have to solve them. He doesn't even have to point people elsewhere. Just listing them is enough and saves a lot of people a lot of time. If you can't be bothered to do that, please take your code down: it is nothing but pollution, keeping us from finding the better code.
This submission, which suggests forking or standardizing Markdown, has currently over 400 points. My guess is that "just use a better implementation and get on with your day" is not a good enough answer for many of us, including Jeff Atwood and David Greenspan.
I'm so tired of this mentality that says basically, if you release something for free on the internet, you are obligated to maintain and support it for the rest of your life. Gruber created this program, for free. You are under no obligation to use it. Don't like it? Here's your money back. It may be true that the code is shit. If you think so, don't use it.
Like other responders, I worry that this mentality causes fewer coders to release their projects, for fear of backlash like this post. Think about it: Your feelings toward Gruber are incredibly negative and hostile, and in fact, you would have better feelings toward him if he had kept Markdown to himself and never released it at all. Does that seem fair to you? If the ill will generated by people like yourself outweighs the good will generated by those who appreciate the code I release, or if I fear that it might, what motivation do I have to release my code?
I don't think they're asking for lifetime maintenance and support. I think they're asking that if the author is aware of bugs and exploits, they should at least make the small effort to alert users who are still downloading their code.
If the exploits are as well-known as the grandparent comment asserts, and Gruber is aware of them, there really is no excuse for him to leave the code up without any warning that it contains known exploits. However, if he has no idea and everyone is assuming he knows without someone telling him, that's not exactly fair.
He enjoys the credit for being the creator of something used by millions every day, but is entirely unwilling to take the responsibility that comes with that creation being a very public mess.
It works for his usage, but all the ambiguities and undefined behaviors affect a huge number of people, and his only response he's made for eight years has been to retain sole moral authority and refuse to use it.
It works for his usage, but all the ambiguities and undefined behaviors affect a huge number of people, and his only response he's made for eight years has been to retain sole moral authority and refuse to use it.
You gain moral authority by actually doing something. If you use markdown, and wish to propose a better markdown than markdown, go for it, I'm sure lots of people will be pleased, but bear in mind that lots of people will whine about any bugs as well, and expect you to work for them for free and spend significant resources and time fixing edge cases which don't matter to you personally, just because you released the source.
If you're ready for that though, of course go ahead and create a better markdown, or help with this proposed spec, Gruber certainly can't stop you. It doesn't really matter what Gruber says, what trolls on a mailing list say, or what you say on this forum about his responsibilities, whether he is self-appointed dictator for life etc (though I'd dispute that), what counts is putting the work in, which is often surprisingly difficult - far more difficult than criticism.
Of course you can do that. I think people's problem is with Gruber's unwillingness to lend any support to those efforts to create a less buggy implementation.
Right now, the canonical markdown implementation isn't very good. It's hard to change what the canonical implementation is without Gruber's support. It doesn't even require much from him - just his blessing.
He isn't under any obligation to do this. No-one thinks he is. But it would be a good thing for him to do.
Frankly, I don't think what Grubber says matters here, and I see why he wouldn't want to engage all the trolls who are enraged by his inaction. Markdown works for him and he prefers it simple if somewhat vague/buggy, if you need something different, build it.
If someone wants to write a spec, a better parser or a better markdown full stop, there is absolutely nothing to stop them. The problem is, people would rather bitch about why no one else is doing anything and complain about gruber than actually do the hard work necessary. Do the work first, then look to gruber for canonization if you must, though by that point his views on the matter would be irrelevant.
Get over yourself. The guy wrote something that suited his own needs and released it so that others could use it too if they wanted. Programmers ported it to other languages because they liked the idea and wanted to see it thrive -- I've used the PHP port in many homespun web apps over the years. Is it perfect? No, and no software is. But when I've needed a script that easily converts line breaks and hyphens into paragraphs and unordered lists (the normal use case I've taken advantage of), it's done the job every time.
This is one of the reasons Why left the programming community. People are not thankful. Even if you release a great idea - with obviously _not_ the best code - the one thing you get is criticism. Maybe also the words that "you are the worst programmer on earth" following the words that "you put your family in such a shame".
You know what programmers think because of such comments? "My code is so bad I can't release it. Even if the idea is good." And this Sir helps no-one.
> You know what programmers think because of such comments? "My code is so bad I can't release it. Even if the idea is good." And this Sir helps no-one.
I agree. This has even stopped me from __starting__ a few FOSS projects I've wanted to develop.
What I love here is that not just satisfied with running down Gruber, you also feel the need to get in a little swipe at Jeff ("as much as [he] leaps at every chance to play the fool"), a man who seems broadly in agreement with you (though is far more constructive in his approach).
No. I was curious and checked - this: https://github.com/waylan/Python-Markdown is slightly below 3k loc mark (2977) excluding extensions, and by the look of it it's much more heavily commented (I didn't strip blank lines or comments at all). Markdown.pl has 1450 loc.
So - no, bullshit, you need to multiply by 2 at most in case of Python :)
Another interesting comparison would be with the Text::Markdown CPAN module which is Gruber's original code & comments converted to an OO interface with POD documentation added + bug fixes.
I'm the author of a Markdown text (prose) editor[1], and can attest to Jeff's statement that all Markdown's parsers suck. The official perl regex-based implementation is a joke. Sundown is great, but only works for cross-compilation to other markup languages; it doesn't work for syntax highlighting, which is what I'm more interested in.
I ended up writing my own in Objective-C. It's not very pretty, and it doesn't use a formal grammar (just a lexer + custom grammar code), but it does the trick. I took a few liberties with the spec: throwing in GitHub-flavored code blocks.
Your editor looks pretty nice; super simple with a gentle element of WYSIWYG.
Can you not tile the background on the homepage, though? It looks horrendous at high resolutions and I suspect you didn't mean for it to be that way: http://cl.ly/image/341C0s1s0M03
(Safari 6.0, OS X 10.8.2)
Woah, how massive is your screen? You're totally right though, it looks awful tiled. I'll have to take care of that.
By the way everybody, I'm working on version 2.0 which is just about a million times better than the original. Hit me up if you'd like to get beta builds and a free copy.
I can't speculate on antidaily's reasoning, but I can tell you why I don't like this way of doing markup. (I thought I was the last one.)
First is the lack of standardization. Asterisks traditionally meant boldface, I thought, but in some of these systems they mean italics. Some use underscores for italics, while others use slashes. And those are just the common conventions; the less frequently used ones tend to be even less standardized.
Second is the fact that the more conventions these languages implement, the more likely I am to emit one unintentionally, and then have to figure out how to escape the input so it's treated literally, if the language even supports that. (Note for instance the long-standing Lisp convention of putting asterisks around special variable names.)
Thirdly, the syntax rules of these languages are often ill-specified and incorrectly implemented, making it difficult to tell at times how to get the effect I want.
* Links are backwards (text,link instead of link,text like HTML anchors)
* Link syntax is pretty arbitrary (why braces and brackets?)
* Single line breaks are swallowed unless you append two spaces to the line. (How is this a "natural" formatting?)
* Footnotes with asterisks turn into bullet lists
Most or all of these are resolved by various implementations, but that's just another reason to hate Markdown: the inconsistencies between implementations.
I don't loathe it, but I don't like it, and I'm sad that WYSIWYG text-editing software is still so bad that a kludge like Markdown seems like a good idea to people. Markdown isn't optimized for people (it's harder to read than properly typeset text, and when writing it you pretty quickly have to remember syntax details, like what sort of brackets to use for links), and it's not optimized for computers, either (it's harder to parse than, say, XML).
This is one of the reasons I've never bought into the Markdown hype and generally avoid using it. Semantic HTML5 tags makes to-HTML compiled languages mostly unnecessary.
Most people don't need to or want to think about it.
Markdown is easily understandable by my wife (and we're using it to format her novels), and she doesn't have time to learn something ultimately as irrelevant to her is a format that makes a computer program happy.
What is Markdown, though, if not "a format which makes a computer program happy"? Presumably, your wife was already familiar with standard typographical conventions like italics for emphasis and indents to start paragraphs. A good text processing system for a computer should let the user deal with these conventions, rather than having to learn a markup system. I'd be interested to hear why you and your wife decided to use Markdown, and what alternatives you considered and rejected.
The other alternatives were essentially opaque formats (e.g., Word or Pages) that when she & I talked about them and the amount of work that I needed to do, she agreed.
She also writes long hand, so this is a minor adaptation for her to write like she does with emails.
The changes suggested are less natural for most people, and HTML is line noise to most people. If she had to learn HTML, my wife could do so—but it isn't necessary for her to learn HTML. It's also easier for me to have to worry about clean-up than her to do so.
We do have points where we have to figure out how to make certain things work (when she has lyrics, that requires a little more massaging on my part—but I insert the bafflegab bit and she just knows to edit around it or inside it).
It isn't perfect, but the results look very good. (In fact, the second novel looks better than the first, which was laid out in Pages and took me three times as long as learning LaTeX to format the second novel. The only problem with the second novel was finding a good font for the PDF version we use as a print-ready copy.)
I really hope that they borrow a lot if not everything from pandoc[1]. My only real complaint with pandoc is the table formatting, but I think fiddlosopher is adding org-mode like table support.
If you have not taken a pandoc for a spin I highly recommend you do so soon. In addition to being a great markdown dialect the pandoc tool set is the swiss army knife of text formatting. It is amazing how many formats pandoc can read and/or write.
EDIT: I spoke too soon, Fiddlosopher continues to impress. I just checked the open issues and a little less than a month ago he added "limited org-table support." Based off of the rest of pandoc "limited" probably means something like 85% to 95% :)
I cannot second this enough. Pandoc Markdown has some nice little tidbits, oddly contrasting to the above, the table syntaxes(yes there are more than one) are pretty darn useful.
"I'm reminded of the guy who decides that there should be
one standard because there are n divergent implementations.
So he goes and writes his own. Now there are n+1 divergent implementations."
That is probably the most likely outcome, but kudos to Jeff for trying.
The idea of Markdown is great, but I found the implementation of links is less than obvious. (haven't tried it in 4 years, so there was probably other issues that I had that I've forgotten)
The problem I inherently always end up having with "parses to HTML" syntax conventions is there are always warts where the syntax is harder to remember than the HTML it is supposed to parse to.
You can hardly blame links for that. There was no widespread hypertext format before HTML for conventional renderings to appear in. Most of the rest of Markdown has analogues in earlier plain text formats and is fairly visually suggestive.
Common Lisp managed to unite several divergent implementations of Lisp (MacLisp, InterLisp, Lisp Machine Lisp, etc.) under a single common specification. This was possible because the Common Lisp standard was not created by some third-party out of dissatisfaction with the other guy's stuff but by significant representatives from all the big camps. The desire was for better interoperability, not imposing ideals on the competition.
I think this effort, if Gruber supports it, is likely to succeed simply by incorporating most of the community. In fact, it could be even easier, because one of the principle motivators for the divergent implementations of Markdown is simply to create concrete specs around a concrete grammar. This doesn't mean there won't be divergences (Scheme, Clojure, OpenLisp, etc.) it just means that those divergences will be principled ("we reject the size", "we desire modern FP techniques") rather than accidental ("we used this regex instead of that to tokenize emphasized text").
(shameless plug) I wrapped Pandoc[1] in a web service and added on nice PDF exports and called it Docverter[2]. It will convert basically anything plain-text, including Markdown, into almost anything else plaintext, HTML, RTF or Docx. I also added rich PDF exports that go through a HTML intermediary.
If this gains some traction I'm sure I'll be adding support for it at some point.
333 comments
[ 4.6 ms ] story [ 324 ms ] threadEdit: I've wondered whether the original Markdown didn't have underline support because <u> was deprecated/removed from HTML. FWIW, <u> is now back in HTML5.
Really, underlines are a useless decoration. That's why HTML took them out. Not sure why they put them back in...
That's an improper use, you want {COMBINING LOW LINE} U+0332 for that.
Dodgy HTML, content pasted in from Word (with crazy styling intact), and a general encouragement for users to see text content in terms of styling rather than structure are all things that it will be delightful to see the end of.
Is this just because it doesn't wrap, and mobile safari doesn't display a scrollbar? (I've never used mobile safari, but I think that's true of the Android browser.)
Quoting with code blocks can be awful, but > is fine even if it's not explicitly formatted.
Pretty sure that's it. OS X (Safari and Chrome, at least) does the same thing unless you have a mouse plugged in. The formatting is such that it doesn't feel like it should scroll, even in the common case of characters being cut in half. Better styling on code blocks would do wonders for this.
The current behavior of Markdown solves this problem very well. I don't want the newlines I enter for non-wrapping editors to remain in the generated HTML.
Perhaps an alternative "profile" could be specified that preserves all line breaks, and sites focused on poetry or song lyrics could use that profile.
Thanks, btw :)
In other words, let the user type:
or ...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.
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.
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.
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.
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
(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.)
This is an [example link]<http://www.example.com/>;
Could I soft-wrap in my editor? Sure, but that would mean that the text files sitting on my hard drive now have very long strings in them making it harder to grep, making it harder to add to git (change a single character, entire line is now a diff :-().
I hope that doesn't become the default.
gqip
?
Changing this, especially for people who implement Markdown parsers, is geek arrogance.
The biggest deployments of Markdown — StackOverflow & GitHub — do not squash line breaks. They made this decision because authors did not assume their line breaks would be discarded.
The change is not geek arrogance. It is, in fact, a reaction to how Normal People use it.
My wife is not a geek or a programmer. She will, if forced, learn the intricacies of an idiotic programmer‘s decision to make something easier for him (and it’s almost invariably a him) in order to participate in a particular forum. This is why people put up with crap like bbcode every single day. That doesn’t mean she enjoys it.
Markdown works because it makes plain text readable and formatted nicely. Markdown works because it works just as well in a plain text email as it does in an HTML-formatted email.
It doesn’t work because some geek says that the people who use heavily geek-oriented sites (StackOverflow & GitHub, to use your examples) are in fact ”Normal People”. (And, just for what it’s worth, I do find the fact that I have to join all my hard-wrapped lines back together in SO & GH comments to be immensely annoying. At least their markdown parser for .markdown files doesn’t do this.)
So, no I am not flat-out wrong. I hear geek whining that parsing is made harder because of a design feature that is present because most people don't think about or want to think about “correct” line-endings.
Before you decide that I’m full of hot air, understand that I am working with my wife’s novel that’s written in Markdown so that I can parse it (possibly using an existing well-written-and-maintained parser like peg-markdown or peg-multimarkdown as an intermediate mechanism) and then transform it into the LaTeX formatting required for making her PDF output and the HTML formatting required for making her EPUB (and thus MOBI) output.
I am well aware of how ugly some of it is…but it makes it easier for her to write her novel without falling back to proprietary formats like .docx. I’m willing to deal with some pain as an implementor in order to minimize what she has to deal with.
As such, I don’t really have a lot of patience for this type of geek whinging.
* Normal People have a consistent expectation regarding the behavior of line breaks.
* Normal People are comfortable with markdown in the first place.
Neither you nor your wife are Normal People.
I feel this way because of the reality that many people will hit enter two dozen times to go to a new page, or to position a bit of text.
In the time that I've been working with computers, what I've come to realize is that most people simply don't have a grasp of the abstractions of the computer—they remember particular incantations that worked for them last time and keep doing them again and again.
My wife is an intelligent person; probably smarter than I am. She speaks three languages and has taught for the last twenty-two years. Watching her use the computer drives me absolutely bonkers because she doesn't use any of the things that I know make the computer easier to use. Neither does her sister. Why? Because neither of them have time to specialize in the use of the computer. They use it a lot, and I've been able to introduce a few things—but only for things that simplify their lives because they integrate into how they already work.
If two of the most intelligent people I know don't have a lot of these expectations…why do people think that most people would expect things to work the way that Jeff has proposed?
In a sibling comment (I only want to reply once), stickfigure says:
“Normal People have a consistent expectation regarding the behavior of line breaks.”
Actually, I don't think that Normal People have any understanding of line breaks at all. They understand letters, words, sentences, paragraphs, and to a degree pages. They know they want something to show up on the page, but they have no understanding of how the computer does its magic to make that happen.
stickfigure: “Normal People are comfortable with markdown in the first place. Neither you nor your wife are Normal People.”
For the second sentence, I agree and disagree. I'm certainly a geek with a more-than-passing interest in layout, formatting, fonts, etc.… This stuff interests me in a way that most people and most geeks certainly would never be interested in it. My wife is also not normal people on some level—she’s married to a geek who can take care of things like this for her. At the same time, she is 100% a computer user and has no interest in learning to program or learning to fight with programs that actively get in her way.
She also doesn't know Markdown as such. She knows a tiny subset that I have introduced to her that provides her with exactly enough to write her novel and for me to format it the way she wants it. (That's the paragraph rules, italics, and headings.) I've shown her a few other things for when she blogs—but even when she's using the Squarespace WYSIWYG editor, I often have to go in and edit the links to make them right.
There's a lot more that I could show her, but she neither has the time nor the interest to learn it.
Email and HTML have not helped this; it is a common expectation that a blank line between two blocks of text represents the paragraph break—at least based on the emails that I've seen over the last two decades.
A fundamental philosophy of Markdown is that a Markdown document looks reasonable when sent via email as text or when sent as a formatted web page. That it's flexible enough to be usable for more than just email and HTML is a bonus.
It's my suspicion that Markdown was written the way it was solely to handle the case of blockquotes having ">" characters at the start of each line, and the reason that mattered is because BBEdit and Mailsmith had commands to wrap text that way, chiefly for quoting mail messages. This happens to fit in very nicely with the way Vim and Emacs wrap paragraphs, and I know there are people who've written novels in both. But I assure you that the vast majority of fiction writers are used to word processors, and for that matter, so are the vast majority of users typing things into text boxes. And if those users wrote a little poem
...the chances are they would just hit return at the end of every line, because that is the way every program they have used in their entire lives works. This is why GitHub and StackOverflow made that change: because Markdown is not like HTML to most people. It's like plain text. In plain text, when you press return it means "end of paragraph." The way Markdown does it -- and the way Hacker News does it, I just discovered! -- violates the principle of least surprise. I am not writing HTML, I am writing text, and I expect it to act like text.(For what it's worth, I've written a collection of short stories in Markdown and created the EPUB from that using my own Python scripts to do so. I am an edge case. Anyone who is writing fiction in a text editor instead of a word processor is also an edge case. Sorry, but it's the truth.)
Which I suppose is the source of Gruber's apparent obstinance, if someone wants to make changes that exchange his design principles for other design principles (I don't think he cares much about naive users), why should he hand them the name of his project?
(to clarify, "apparent obstinance" is me doing a poor job of keeping sarcasm out of my post, I don't have a problem with Gruber insisting that the markdown name is his)
But I like the idea that a shared file will look about the same without relying on there being a smart editor on the other end.
http://stackoverflow.com/editing-help#linebreaks
It is a pretty common mistake for new users to make, though most of the time an editor will fix it pretty quickly and the user will learn.
http://stackoverflow.com/editing-help#linebreaks
Notice the requirement for two spaces at the end, ONLY Github doesn't do that.
* people typing markdown in text files, where you want to split paragraphs into word-wrapped lines of a sensible length, and consecutive non-blank lines form paragraphs just as they always have in text files;
* and people typing markdown into text entry boxes on web pages, where you would like pressing the <enter> key to actually mean something.
These two situations probably prefer a different default.
This way if the user presses <Enter><Enter> then the JS can remove the extra two spaces and it will still be valid markdown.
I think this behavior is the better route because it accommodates both crowds. The line-wrap folks can just press enter twice; no biggie. But the console and vim users of the world can continue using line-breaks the way that work best for their environment.
On the flip side, making a single enter start a new paragraph wouldn't really help the GUI users (what's the difference between one line break and two, really?) but it would really hurt the console users of the world
IMHO, pandoc markdown support is the mother of all implement featuring lots of goodies (table and footnote to name 2)
How can this be harder than creating table with Word? Word always gets in the way. Word appears to be easier but down the road, it always end up as a painful process.
For me just the benefit of being mergable and delegating styling at the end of the tool chain is just plain great.
http://johnmacfarlane.net/pandoc/README.html#tables
Edit: rendering issues!
I think I'll just "preprocess" the file, looking for something like !csvtable(filename.csv).
Wrote the script (it worked), but some specific complex features from Word still were missed ("how do I do a reference to a picture?") and couldn't be easily supported by pandoc or this script.
Though for a brief time of going full-mode procrastinator and writing another markup language...
Then I had to admit the whole thing wasn't really working and now recommend we move back to Microsoft Word because it's easier.
A day of Total fail, and procrastination, and making everyone install MikTex, pandoc and Python.
I hope I don't regret for suggesting we use Git...
But I have learned to love Markdown too, I hope in the future, distant future: Someone will create a language that integrates HTML and CSS into a nice Markdown-like language.
Not closing <li> is good, but I'd avoid it for <p>.
I hate its URL handling.
And of course it needed Sphinx to make it work across more than one source file which means we now have two dialects.
I do wish everyone would just agree on one syntax and be done with it.
All my doc is in Sphinx so I play it safe, and all directives need to be supported in whatever version of docutils and rst2pdf are installed across the various developer machines. So for the moment I am stuck with ascii art.
Plowing through the sources to figure out where that happens... (docutils?).
Any thoughs/pointers would be welcome from a passing reader of this comment...
I cannot understand for what reason MD has become popular, it has an annoying and confusing syntax for half of the things, supports many less things than others and is not stricly better in any way I can think of.
Compared to rst it's a lot easier to write links. I hadn't even heard of textile, but its link syntax also seems harder to write than markdown's. WikiCreole might be better, but right now figuring out what syntax a given wiki will support is far more of a crapshoot than using an arbitrary markdown implementation.
I'm using reST for everything: docs for people (converting them to html and doc before sending), doc-comments in every language I use, be python, T-SQL, java or F#
I don't think it's ideal but it's just works
If only a couple sites band together, then I see it more like this:
http://xkcd.com/927/
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions
Which is appealing to me, and many others I suspect.
[1]: http://daringfireball.net/projects/markdown/
BBCode isn't inherently "bad" if you're just writing something and won't ever edit it again but for anything that you will need to edit / review in the future it can be a serious pain in the ass to look through.
These are the two examples I used:
vs. BBCode was written to be written, it's no more difficult to write than it is to write: but when reading the source (for maintaining) it... sucks, because it feels un-natural. With the Markdown version of linking (to pick a basic example) you can read a sentence how the person reading the processed version would read it: That reads as "A search engine called google" and then you see that google is a hyperlink. With BBCode it would read: So first you read "A search engine called" then you see it's a URL and then you see "google". It can get very frustrating when you're looking at huge swathes of text written in a similar style.Nobody should be using the original script, and unfortunately many of the other implementations out there are direct transliterations that replicate all of its absurd errors, like where if you mention the MD5 hash of another token in the document, the hash will be replaced with the token, because it uses that as an inline escaping mechanism! Reddit got hit with a XSS virus that got through their filters because of it: http://blog.reddit.com/2009/09/we-had-some-bugs-and-it-hurt-...
See the changelog for what started as a PHP transliteration and turned into a rewrite that squashed 125 (!) unacknowledged bugs: http://michelf.com/projects/php-markdown/
The worst part is that he outright refuses to either disclaim or fix his implementation, and so far he's repudiated everyone else's attempts to do so. He's a terrible programmer and a worse maintainer, he really still thinks the documentation on his site is comprehensive and canonical. As much as Jeff Atwood leaps at every chance to play the fool, there's no way his directorship can be anything but an improvement.
I think there's something to your post, but the tone makes me want to dismiss it. I know, stupid emotions.
This internet lynch mob mentality... I wonder how much this discourages people from releasing things. So, Gruber releases markdown.pl. People like it. People love it. People use it, people reuse it, people rewrite it. Next think you know, he's being insulted on the internet because he released something he wrote to serve his needs and not passing on some sort of figurative mantle or blessing.
Being great at designing a format and writing code are two different things: one can be great at once while being terrible at the other.
It is a great format.
The original parser (and specification) has serious problems.
Oh please, double standards like this disgust me. Microsoft had shit slung at it for years on end by the tech community because IE was terrible and held back innovation on the web, but no one claimed that IE is "not so terrible" just because everyone cared about it.
The difference with Gruber is that he's a darling of the tech community because he's Apple-anointed nobility. But as a programmer, in my eyes (and in the eyes of any other objective observers) he's absolute shit.
Abandoning basic etiquette that you should have learned in primary school and calling someone "absolute shit" is not cool.
I didn't care that IE was terrible (until v3 or whenever), I cared that Microsoft went to all the major PC manufacturers and told them that their licensing deals were toast if they preloaded Netscape.
I didn't care that Word was a crappy word processor, I cared that they used their market position on office documents to make minor incompatibilities that prevented WordPerfect from interoperating.
I didn't care that Windows file sharing wasn't half as good as NFS, I care that they continually fucked with the SMB protocol so that no one could sell UNIX machines that could share with Windows networks.
It has been an absolute pleasure watching that Microsoft's power over device makers disappear. The world is better off for it, and Microsoft will always be an asshole in my book.
Over those years it's grown in usage exponentially, and so has his fame as a sportswriter for team Apple. Throughout that period he's continued to brush off all kinds of attempts to clean up bugs, define ambiguous behavior, or fix the security vulnerabilities. It hasn't mattered what approach people have taken, he just does not give a shit. Here's an example from last week: http://six.pairlist.net/pipermail/markdown-discuss/2012-Octo...
He's spent so long burning off any goodwill I would have for him on the matter, being cordial just isn't a priority anymore. NERD RAGE.
You're right: he just does not give a shit. I can see why. What possible upside could there be to engaging with someone who handles themselves like you are here?
Imagine that you're a mechanic working on a motor that uses the ProprietaryNew fastener (hex heads? so 20th century!). Unfortunately, the only ProprietaryNew wrenches are made out of cheap metal, and the sockets strip with regularity. You can't imagine saying a few nasty words about the parentage of everyone in ProprietaryNewCo?
From a comment on Twitter yesterday in response to someone, it doesn't seem that Gruber is particularly interested in engaging with this (though I may be wrong). If that is the case I suspect we'll see a forking of the project and we'll get to see whether a committee will do better.
It may well do - Jeff has a good track record at getting things done and is well respected and well liked - but personally I wouldn't put my mortgage on it because as well intentioned as these things are we all know how design by committee usually turns out.
Care to show us your alternative? It'll be on Github or GoogleCode, or maybe your personal blog, somewhere we can download it, try it out, and criticize it too, right?
Surely 8 years of rage is enough encouragement to write your own replacement for ~1000 odd lines of Perl?
Or by "enraged", did you mean "annoyed enough to write critical posts on random internet sites, but not motivated enough to spend an evening or two solving the problem myself"?
"NERD RAGE" indeed…
The real problem cannot be solved without some forward action on his part. He has refused over and over again.
Sure it can - you write something better, then get everybody who's already using Gruber's version or one of it's presumably also-flawed reimplementations to switch to yours. Or, is "8 years of enragement" really just keyboard-warrior-hyperbole on your part and an excuse to criticize someone who's achieved widespread adoption of some code you claim is 2nd rate, but which haven't bothered to improve or replace?
Besides, it sounds to me like David Greenspan has come up with a fine solution.
At some point there's no constructive criticism left to give.
His program is bad and he should feel bad
The dude released a script to the public under a free software license and people used it. If you think it's bad, fork it and fix it, otherwise don't use it, that's how the open source ecosystem works.
Your project can cost people a lot of time if it promises, but doesn't deliver. I just spent quite some time searching for a decent XSD parser in Ruby, haveing to wade through a score of projects that promise to do what I want, but turn out to be incomplete, buggy or otherwise useless to me. Many people will perform the same quest and together a lot of time is wasted, which could have been prevented if people would not just publish any damned thing, but would also take the time to properly document its state.
Open source projects without proper documentation, I can do without. This problem will only become worse in decades to come. I sure as hell hope github will start purging old projects with too many 'not useful' votes within the next few years. Otherwise it'll be a morass of stink where the gems can no longer be found.
He just needs to add a sentence or two to his website and he'll save countless developers a ton of headache. He just doesn't give a shit.
It's pathetic.
He wrote a text-to-HTML parser with a particularly elegant little language design and got on with his life, which involves writing more than keeping up with bug reports in Perl scripts. Get over yourself; comments like this make us all look bad.
unfortunately many of the other implementations out there are direct transliterations that replicate all of its absurd errors
he outright refuses to either disclaim or fix his implementation
This is important to know if you are interested in Markdown.
Personally, I encountered edge cases almost as soon as I started using it.
I believe markdown.pl is being blamed for over 100 bugs. Not just security flaws.
> I suppose the memory corruption bugs in the "optimized" C Markdown parsers are somehow his fault too?
Strawman, you're better than that.
> He wrote a text-to-HTML parser with a particularly elegant little language design and got on with his life
And he did a horrible job of it. Horrible. But he considers himself the BDFL of Markdown. Break that down for me.
> which involves writing more than keeping up with bug reports in Perl scripts
He clearly can't keep up with any bug reports, so it's good his life is more broad than bug reports.
> Get over yourself; comments like this make us all look bad.
No, comments like this make us look like we have higher expectations than "it worked on my machine, suck a dick!"
Christ, you're being a dick. All John Gruber did to you was design a minimalist markup language and write a quick-and-dirty proof-of-concept Perl script to implement it. Just use a better implementation and get on with your day.
No you don't, that's insane.
People like Gruber, with an audience, a following, should set an example. If his code has bugs and he is informed of those bugs, he should take a few minutes to list those bugs. He doesn't have to solve them. He doesn't even have to point people elsewhere. Just listing them is enough and saves a lot of people a lot of time. If you can't be bothered to do that, please take your code down: it is nothing but pollution, keeping us from finding the better code.
Well he needs to be something other than a pathetic apple fanboy! :D
We all write code with bugs and flaws and we sometimes release it online.
'Fix or deprecate' is not an unrealistic obligation on a technology journalist with a public persona and a large readership.
Like other responders, I worry that this mentality causes fewer coders to release their projects, for fear of backlash like this post. Think about it: Your feelings toward Gruber are incredibly negative and hostile, and in fact, you would have better feelings toward him if he had kept Markdown to himself and never released it at all. Does that seem fair to you? If the ill will generated by people like yourself outweighs the good will generated by those who appreciate the code I release, or if I fear that it might, what motivation do I have to release my code?
If the exploits are as well-known as the grandparent comment asserts, and Gruber is aware of them, there really is no excuse for him to leave the code up without any warning that it contains known exploits. However, if he has no idea and everyone is assuming he knows without someone telling him, that's not exactly fair.
It’s that he thinks the best option is to do nothing. He claims the title of BDFL without playing the role.
See his first reply to the Markdown mailing list in nearly three years: http://six.pairlist.net/pipermail/markdown-discuss/2012-Octo...
He enjoys the credit for being the creator of something used by millions every day, but is entirely unwilling to take the responsibility that comes with that creation being a very public mess.
It works for his usage, but all the ambiguities and undefined behaviors affect a huge number of people, and his only response he's made for eight years has been to retain sole moral authority and refuse to use it.
You gain moral authority by actually doing something. If you use markdown, and wish to propose a better markdown than markdown, go for it, I'm sure lots of people will be pleased, but bear in mind that lots of people will whine about any bugs as well, and expect you to work for them for free and spend significant resources and time fixing edge cases which don't matter to you personally, just because you released the source.
If you're ready for that though, of course go ahead and create a better markdown, or help with this proposed spec, Gruber certainly can't stop you. It doesn't really matter what Gruber says, what trolls on a mailing list say, or what you say on this forum about his responsibilities, whether he is self-appointed dictator for life etc (though I'd dispute that), what counts is putting the work in, which is often surprisingly difficult - far more difficult than criticism.
Right now, the canonical markdown implementation isn't very good. It's hard to change what the canonical implementation is without Gruber's support. It doesn't even require much from him - just his blessing.
He isn't under any obligation to do this. No-one thinks he is. But it would be a good thing for him to do.
If someone wants to write a spec, a better parser or a better markdown full stop, there is absolutely nothing to stop them. The problem is, people would rather bitch about why no one else is doing anything and complain about gruber than actually do the hard work necessary. Do the work first, then look to gruber for canonization if you must, though by that point his views on the matter would be irrelevant.
You may want to look into seL4. (If you consider formal verification to be perfection, that is.)
You know what programmers think because of such comments? "My code is so bad I can't release it. Even if the idea is good." And this Sir helps no-one.
Stop this shit.
I agree. This has even stopped me from __starting__ a few FOSS projects I've wanted to develop.
Stay classy.
Perl makes it look small, if you have to write something like this in Java or Python, multiply the LOC by at least 20. But I assure it will be higher.
So - no, bullshit, you need to multiply by 2 at most in case of Python :)
This comes (including blank lines, comments & POD) to 1739 loc - https://metacpan.org/source/BOBTFISH/Text-Markdown-1.000031/...
I ended up writing my own in Objective-C. It's not very pretty, and it doesn't use a formal grammar (just a lexer + custom grammar code), but it does the trick. I took a few liberties with the spec: throwing in GitHub-flavored code blocks.
https://gist.github.com/29dabe4b6e762ee221df
[1]: http://getmacchiato.com/
1: http://www.pell.portland.or.us/~orc/Code/discount/
Can you not tile the background on the homepage, though? It looks horrendous at high resolutions and I suspect you didn't mean for it to be that way: http://cl.ly/image/341C0s1s0M03 (Safari 6.0, OS X 10.8.2)
By the way everybody, I'm working on version 2.0 which is just about a million times better than the original. Hit me up if you'd like to get beta builds and a free copy.
First is the lack of standardization. Asterisks traditionally meant boldface, I thought, but in some of these systems they mean italics. Some use underscores for italics, while others use slashes. And those are just the common conventions; the less frequently used ones tend to be even less standardized.
Second is the fact that the more conventions these languages implement, the more likely I am to emit one unintentionally, and then have to figure out how to escape the input so it's treated literally, if the language even supports that. (Note for instance the long-standing Lisp convention of putting asterisks around special variable names.)
Thirdly, the syntax rules of these languages are often ill-specified and incorrectly implemented, making it difficult to tell at times how to get the effect I want.
EDITED to add: if you're wondering what I would suggest as an alternative to Markdown-style markup, this is an example of the kind of thing I prefer: http://nbsp.io/development/doccy-a-mid-weight-markup-languag...
The syntax is uniform, but much easier to type than bare HTML.
* Links with parentheses often break
* Intra-word underscores have to be escaped
* Links are backwards (text,link instead of link,text like HTML anchors)
* Link syntax is pretty arbitrary (why braces and brackets?)
* Single line breaks are swallowed unless you append two spaces to the line. (How is this a "natural" formatting?)
* Footnotes with asterisks turn into bullet lists
Most or all of these are resolved by various implementations, but that's just another reason to hate Markdown: the inconsistencies between implementations.
Most people don't need to or want to think about it.
Markdown is easily understandable by my wife (and we're using it to format her novels), and she doesn't have time to learn something ultimately as irrelevant to her is a format that makes a computer program happy.
She also writes long hand, so this is a minor adaptation for her to write like she does with emails.
The changes suggested are less natural for most people, and HTML is line noise to most people. If she had to learn HTML, my wife could do so—but it isn't necessary for her to learn HTML. It's also easier for me to have to worry about clean-up than her to do so.
We do have points where we have to figure out how to make certain things work (when she has lyrics, that requires a little more massaging on my part—but I insert the bafflegab bit and she just knows to edit around it or inside it).
It isn't perfect, but the results look very good. (In fact, the second novel looks better than the first, which was laid out in Pages and took me three times as long as learning LaTeX to format the second novel. The only problem with the second novel was finding a good font for the PDF version we use as a print-ready copy.)
If you have not taken a pandoc for a spin I highly recommend you do so soon. In addition to being a great markdown dialect the pandoc tool set is the swiss army knife of text formatting. It is amazing how many formats pandoc can read and/or write.
[1] http://johnmacfarlane.net/pandoc/README.html
EDIT: I spoke too soon, Fiddlosopher continues to impress. I just checked the open issues and a little less than a month ago he added "limited org-table support." Based off of the rest of pandoc "limited" probably means something like 85% to 95% :)
https://github.com/jgm/pandoc/issues/519
The idea of Markdown is great, but I found the implementation of links is less than obvious. (haven't tried it in 4 years, so there was probably other issues that I had that I've forgotten)
The problem I inherently always end up having with "parses to HTML" syntax conventions is there are always warts where the syntax is harder to remember than the HTML it is supposed to parse to.
http://xkcd.com/927/
Common Lisp managed to unite several divergent implementations of Lisp (MacLisp, InterLisp, Lisp Machine Lisp, etc.) under a single common specification. This was possible because the Common Lisp standard was not created by some third-party out of dissatisfaction with the other guy's stuff but by significant representatives from all the big camps. The desire was for better interoperability, not imposing ideals on the competition.
I think this effort, if Gruber supports it, is likely to succeed simply by incorporating most of the community. In fact, it could be even easier, because one of the principle motivators for the divergent implementations of Markdown is simply to create concrete specs around a concrete grammar. This doesn't mean there won't be divergences (Scheme, Clojure, OpenLisp, etc.) it just means that those divergences will be principled ("we reject the size", "we desire modern FP techniques") rather than accidental ("we used this regex instead of that to tokenize emphasized text").
If this gains some traction I'm sure I'll be adding support for it at some point.
[1]: a wonderful almost-everything-to-everything text converter http://johnmacfarlane.net/pandoc/
[2]: http://www.docverter.com
1. http://johnmacfarlane.net/pandoc/