I would hardly call a plugin that automates and highlights a fancy editor. Most editors do something similar, github and emacs markdown mode come to mind.
While your 'tone' may earn you disapproval, I see what you're saying.. This may well be one of those moments where 'cool' trumps 'practical', though .. it is cool to see colors where once there were '###'-s, but to my eyes, the ASCII'ness of markdown is worth the considerable effort, in this day and age, to propagate. This is not that.
I agree, that's what I thought was the point. The reason I like using Markdown is because it actually sticks to that promise quite well.
I write Markdown every day. I use it to take notes, to write blog posts, write documents, everything. In fact, because of Pandoc (and a little bit of LaTex), every document I've written in the last year and a half I have written using Markdown. Through all of that writing, I've never used any kind of special editor or highlighting, just a plain text-editor.
Now I have about 30 more pages of Markdown I've got to write today.
The bigger deal to me is having a completely portable format that I can just copy and paste between any number of editors and services without worrying about formatting. Doing that in Word? Not so much.
You definitely don't need a markdown specific editor, but I don't see a problem with using one if it makes writing md more efficient.
I personally like MarkdownPad (http://markdownpad.com/, windows only),
but for some non-basic features (GitHub Flavored Markdown, PDF export) you have to buy it for $15.
I dropped Mou in favour of LightPaper http://clockworkengine.com/lightpaper-mac which has more features (tabs, edit or preview panels hiding), better themes and customisation imho.
Mou is a great app, it also has a GitHub style live preview which is very nice, but it can be very slow on large Markdown files. I also had some problems with the syntax highlighter on lists.
No, our style guide clearly states that you should be using <em> now, not <i>.
...OK, an exaggeration. But it's much simpler than HTML. If people input with HTML then you're going to need to filter which tags you do and don't want to pass through. Markdown just gets rid of stuff like that. Not to mention automatic paragraphing.
> You'd change your mind about "everybody knows HTML" ...
Absolutely. You could've stopped there without any further caveats. The comment above I think is HN arrogance, assuming that the rest of the web is at a certain minimum level of tech literacy.
So many people post facebook updates or online comments and don't what what HTML is. I know someone (relatively young, uses the internet daily) who doesn't know what a browser is.
That aside, if given the choice, I would voluntarily use Markdown for comments all day long, no contest. For example a bullet/unordered list[1] needs so many awkward tags, whereas a Markdown list is much simpler, and much more intuitive for those who don't know HTML[2].
Well for reddit comments, the vast majority of the comments I typically make will make use of quotes, bold, italics or lists (the comments that include markdown), I use stuff like tables quite infrequently. So even remembering a small subset of the markdown will make my comments much more readable. I learn the features I use regularly, from reading other comments, that's how I picked up markdown originally.
I'm learning Python, I don't expect to learn all the features, hopefully I will learn a small subset, enough to be dangerous!
> Well, why not a WYSIWYG editor (similar to that on Stack Overflow) that generates HTML?
Absolutely, this is a good solution also. I personally like knowing the markdown features, I guess, but that's just me ;-) There is an extremely similar feature in the RES addon which allows live preview, not possible on a smaller screen though. It even includes a helpful list of markdown features for the newbie.
What's the markdown equivalent of that? And then, more importantly, what's the HTML equivalent of that markdown? Clearly not that complicated.
My point is, what you're trying to accomplish with markdown is just as easy to accomplish with good old-fashioned HTML.
If you want nice CSS, define it and tell your users how to use it.
Rather than running everything through markdown, run it through an XHTML whitelist.
You don't write an entire page in markdown, generally - you just write a fragment. So, let me write an HTML fragment, and you can wrap it with the headers you need to.
Hacker News could probably expect a large majority of their users to be able to handle it. Maybe with complaints, but handle it.
I had a personal Wiki which was based off of some open source Wiki. The first thing I did was removed Markdown, because it was completely pointless for me. This was 14 years ago. All I wanted was a web interface to edit HTML and view it later. For the most part, I just had lists and links, and sometimes notes and status reports.
Mainly, I could go to localhost/psychometry in my browser bar, and get immediately presented with "This page doesn't exist, type in the textbox below to write the HTML for the page". It was super handy.
Hmm, it was some C++ code someone had made based off of MoinMoin, and it had something like Markdown. Specifically camel-casing being automatic links, I remember wanting to get rid of.
"setext" was short for "structured e-text", and yes, that's
why "restructured-text" put the "re" in front of its name,
because they were "redoing" the structured-e-text of setext.
but even ian feldman would tell you (if you could find him)
that he was merely leveraging the well-known conventions of
the fledging internet at the time, such as usenet listserves.
"light-markup" is something that _the_masses_ "invented".
I am not a fan of markdown, but I think it shines in niche uses.
For instance typing two "*" or 5 "<>/" are a completely different experience on an iPad for instance. For a sublime text plugin it seems irrelevant, but if you edit your files in different environments it's a boon.
It's also a lot more parseable and sanitizable than html, and doesn't need much escaping when moved around.
i think most people will tell you that it _is_ easier.
first, it's one character, as opposed to three or four.
and, as you get into longer tags, like "em" or "strong",
so grows the amount of excess typing you'll need to do.
(i won't mention "blockquote", but you know that i could!)
second, it's the _same_ on both sides, not different.
and there's no question about the direction of a slash,
which is not intuitive to people who don't code .html.
third, let us recall that some structures, like lists,
need internal "li/li" tag-pairs on each individual item,
as well as the "ul/ul" tag-pair located on the outside.
fourth, all the brackets/tags are intrusive when editing.
your mind has to "look past" the markup to see the text,
and those distractions make writing more difficult than
it already is, and there's no reason to put up with that.
fifth, the distraction gets even worse if you want to have
curly-quotes, because there's crap like “this”;
and let’s all agree we don’t need that garbage!
sixth, .html can get downright complicated, very quickly.
can you tell me how "pre", "code", and "keyboard" differ?
probably not, not just off the top of your head, anyway...
and what's the abbreviation tag again? i always forget it.
and seventh, you mean i have to put a "p" tag on _every_
paragraph? _every_ one? can't it just do _that_ for me?
it's pretty obvious that blank line means "new paragraph".
i mean, seriously, sometimes computers are _so_stupid!_
so, um, yeah, actually, light-markup is a _lot_ easier.
still... if _you_ prefer to write in .html, be my guest!
but me? well, i've got way more important things to do.
Picture a WYSIWYG or maybe a preview-below editor, much like the Stack Exchange ones, but outputting HTML behind the scenes rather than markup.
Now there's no character to type for italics, you highlight what you want in italics, and push the button. Or type Control-I. <i> and </i> magically appear. Pretty soon, you might even learn what they mean.
A "make bullet" or "make numbered" list button. An indent/unindent button. Much like GMail Compose or Google Drive.
Most of the time, people don't bother with even Markup. All those asterisks and double-asterisks. Many people just post links, rather than that paren / brace stuff like on Reddit.
Yes, HTML can get downright complicated. The vast majority of the time, people don't even Markup.
As for p tags, the site could have white-space: pre-wrap style applied to all comments. Boom.
And again, markup is nice and all. So is Notepad. But I like HTML, and I like IDEs.
And to be clear, I'm not saying a site would allow all HTML tags (that would be suicide with the first <script>), but would whitelist them. Then, there's no CPU time to render Markup into HTML. So, there's that.
Fine, I'm saying that showing a user they screwed up is neither a technology challenge, or a user interface challenge.
If I type squirtle right now in my browser, Chrome underlines it in red. Everyone's used to this.
Showing <code><code> with the second code underlined in red, to tell the user to change it to </code> is neither technically difficult, or confusing to users.
My point being, you seem to be arguing that markup is hard to make mistakes in. I'm retorting that helping users correct their HTML mistakes is not hard, and is a valid response to the problem that <code><code> poses.
I think a really cool new markdown editor that I discovered a little over a month ago is Stackedit: https://stackedit.io/
Stored locally or on DB/GDrive, latex support, and a very complete product. The interface is a little unintuitive at first, but I highly suggest anyone that writes blog posts in markdown to check it out.
> Instead of a plethora of backends, Madoko concentrates on generating either HTML or high-quality PDF files through LaTeX. There has been a lot of effort in Madoko to make the LaTeX generation robust and customizable while integrating well with the various academic document- and bibliography styles. This makes it possible to write articles using just Madoko and get both a high-quality print format (PDF) and a great looking HTML page.
I have been using sublime-markdown-extended (https://github.com/jonschlinkert/sublime-markdown-extended), which has the nice feature of recognising and highlighting frontmatter blocks. Would love to see frontmatter support in the MarkdownEditing package as well!
If you are looking for a standalone Markdown editor for OSX, LightPaper is a great app. Used Mou for a while but now switched to LightPaper for features and stability. http://clockworkengine.com/lightpaper-mac/
51 comments
[ 3.3 ms ] story [ 70.0 ms ] threadI write Markdown every day. I use it to take notes, to write blog posts, write documents, everything. In fact, because of Pandoc (and a little bit of LaTex), every document I've written in the last year and a half I have written using Markdown. Through all of that writing, I've never used any kind of special editor or highlighting, just a plain text-editor.
Now I have about 30 more pages of Markdown I've got to write today.
You definitely don't need a markdown specific editor, but I don't see a problem with using one if it makes writing md more efficient.
Yes, I realize there's other themes, but they're terrible too. I find light text on a dark background fine for code, but terrible for writing prose.
For a good Markdown editor, I recommend Mou. It's been my choice for a while now. http://mouapp.com
Well, it is to me. I can't stand too much contrast, it hurts my eyes.
Ensure that you're editing the right flavor file, and restart ST for good measure.
I've already created an Atom package that runs that on save:
https://atom.io/packages/markdown-format
* this* isn't any easier than <i>this</i> to me.
Of course, I may be biased.
...OK, an exaggeration. But it's much simpler than HTML. If people input with HTML then you're going to need to filter which tags you do and don't want to pass through. Markdown just gets rid of stuff like that. Not to mention automatic paragraphing.
I don't know. Everybody knows HTML. It's pretty easy.
> If people input with HTML then you're going to need to filter which tags you do and don't want to pass through.
That's a solved problem¹²³.
> Markdown just gets rid of stuff like that.
And you can only use a subset of HTML. I guess there are pros and cons.
> Not to mention automatic paragraphing.
¹https://code.google.com/p/owasp-java-html-sanitizer/²https://github.com/rgrove/sanitize
³http://code.google.com/p/google-caja/wiki/JsHtmlSanitizer
Little things like <em> or <i>, and browsers being very tolerant of appalling HTML, mean that a lot of people only sort of know HTML.
I do wosh that BBCode or Markdown had better standards.
Absolutely. You could've stopped there without any further caveats. The comment above I think is HN arrogance, assuming that the rest of the web is at a certain minimum level of tech literacy.
So many people post facebook updates or online comments and don't what what HTML is. I know someone (relatively young, uses the internet daily) who doesn't know what a browser is.
That aside, if given the choice, I would voluntarily use Markdown for comments all day long, no contest. For example a bullet/unordered list[1] needs so many awkward tags, whereas a Markdown list is much simpler, and much more intuitive for those who don't know HTML[2].
[1] http://www.w3schools.com/tags/tag_ul.asp
[2] http://www.reddit.com/r/reddit.com/comments/6ewgt/reddit_mar...
How about the other 0.1%? Well, why not a WYSIWYG editor (similar to that on Stack Overflow) that generates HTML? I mean, what are we, barbarians?!
I'll note that the source to your Reddit article is 322 lines long! That'a lot to remember!
I'm learning Python, I don't expect to learn all the features, hopefully I will learn a small subset, enough to be dangerous!
> Well, why not a WYSIWYG editor (similar to that on Stack Overflow) that generates HTML?
Absolutely, this is a good solution also. I personally like knowing the markdown features, I guess, but that's just me ;-) There is an extremely similar feature in the RES addon which allows live preview, not possible on a smaller screen though. It even includes a helpful list of markdown features for the newbie.
My point is, what you're trying to accomplish with markdown is just as easy to accomplish with good old-fashioned HTML.
If you want nice CSS, define it and tell your users how to use it.
Rather than running everything through markdown, run it through an XHTML whitelist.
You don't write an entire page in markdown, generally - you just write a fragment. So, let me write an HTML fragment, and you can wrap it with the headers you need to.
You cannot expect users to know HTML and CSS to comment on your website.
Hacker News could probably expect a large majority of their users to be able to handle it. Maybe with complaints, but handle it.
I had a personal Wiki which was based off of some open source Wiki. The first thing I did was removed Markdown, because it was completely pointless for me. This was 14 years ago. All I wanted was a web interface to edit HTML and view it later. For the most part, I just had lists and links, and sometimes notes and status reports.
Mainly, I could go to localhost/psychometry in my browser bar, and get immediately presented with "This page doesn't exist, type in the textbox below to write the HTML for the page". It was super handy.
[0] - http://en.wikipedia.org/wiki/Markdown
but it's not entirely accurate to say it was "invented".
let me be more clear: markdown was _not_ "invented".
gruber was blogging with movable type, which was using the _textile_ light-markup system created by dean allen.
so he didn't even come up with the _idea_ himself!
of course, neither did allen. light-markup systems were _the_zeitgeist_ around the turn of the century:
* restructured-text was adopted for python documentation.
(.rst -wikipedia.org/wiki/restructuredtext -- david goodger)
* asciidoc had a big list of org-users. (still does.)
(asciidoc -- wikipedia.org/wiki/asciidoc -- stuart rackham)
* and there were other early entrants that are still alive.
(txt2tags -- wikipedia.org/wiki/txt2tags -- txt2tags team)
and dean allen's textile had a fairly solid reach by 2004:
* textile -- wikipedia.org/wiki/textpattern -- dean allen
* texy -- code.google.com/p/texy-- david grudl
* redcloth -- rubygems.org/gems/RedCloth/versions -- garber
* textpattern -- textpattern.com -- dean allen
but the first that i'd call "light markup" was "setext":
* 1992 -- http://en.wikipedia.org/wiki/setext -- ian feldman
"setext" was short for "structured e-text", and yes, that's why "restructured-text" put the "re" in front of its name, because they were "redoing" the structured-e-text of setext.
but even ian feldman would tell you (if you could find him) that he was merely leveraging the well-known conventions of the fledging internet at the time, such as usenet listserves.
"light-markup" is something that _the_masses_ "invented".
-bowerbird
For instance typing two "*" or 5 "<>/" are a completely different experience on an iPad for instance. For a sublime text plugin it seems irrelevant, but if you edit your files in different environments it's a boon.
It's also a lot more parseable and sanitizable than html, and doesn't need much escaping when moved around.
first, it's one character, as opposed to three or four. and, as you get into longer tags, like "em" or "strong", so grows the amount of excess typing you'll need to do. (i won't mention "blockquote", but you know that i could!)
second, it's the _same_ on both sides, not different. and there's no question about the direction of a slash, which is not intuitive to people who don't code .html.
third, let us recall that some structures, like lists, need internal "li/li" tag-pairs on each individual item, as well as the "ul/ul" tag-pair located on the outside.
fourth, all the brackets/tags are intrusive when editing. your mind has to "look past" the markup to see the text, and those distractions make writing more difficult than it already is, and there's no reason to put up with that.
fifth, the distraction gets even worse if you want to have curly-quotes, because there's crap like “this”; and let’s all agree we don’t need that garbage!
sixth, .html can get downright complicated, very quickly. can you tell me how "pre", "code", and "keyboard" differ? probably not, not just off the top of your head, anyway... and what's the abbreviation tag again? i always forget it.
and seventh, you mean i have to put a "p" tag on _every_ paragraph? _every_ one? can't it just do _that_ for me? it's pretty obvious that blank line means "new paragraph". i mean, seriously, sometimes computers are _so_stupid!_
so, um, yeah, actually, light-markup is a _lot_ easier.
still... if _you_ prefer to write in .html, be my guest!
but me? well, i've got way more important things to do.
-bowerbird
Now there's no character to type for italics, you highlight what you want in italics, and push the button. Or type Control-I. <i> and </i> magically appear. Pretty soon, you might even learn what they mean.
A "make bullet" or "make numbered" list button. An indent/unindent button. Much like GMail Compose or Google Drive.
Most of the time, people don't bother with even Markup. All those asterisks and double-asterisks. Many people just post links, rather than that paren / brace stuff like on Reddit.
Yes, HTML can get downright complicated. The vast majority of the time, people don't even Markup.
As for p tags, the site could have white-space: pre-wrap style applied to all comments. Boom.
And again, markup is nice and all. So is Notepad. But I like HTML, and I like IDEs.
And to be clear, I'm not saying a site would allow all HTML tags (that would be suicide with the first <script>), but would whitelist them. Then, there's no CPU time to render Markup into HTML. So, there's that.
With HTML it's obvious that the plain text is an intermediate representation that always expects to be further interpreted.
bold, _italic_. Underlining is only used by typewriters or for links and is barbaric and should be avoided for almost all other uses.
https://github.com/go-gl/glfw3/commit/c48f1acb53fec41115b731...
Fine, I'm saying that showing a user they screwed up is neither a technology challenge, or a user interface challenge.
If I type squirtle right now in my browser, Chrome underlines it in red. Everyone's used to this.
Showing <code><code> with the second code underlined in red, to tell the user to change it to </code> is neither technically difficult, or confusing to users.
My point being, you seem to be arguing that markup is hard to make mistakes in. I'm retorting that helping users correct their HTML mistakes is not hard, and is a valid response to the problem that <code><code> poses.
Markdown was and is for html moms. Whereas, I would often type <h2>heading</h2> in the .doc files. never-mind.
Stored locally or on DB/GDrive, latex support, and a very complete product. The interface is a little unintuitive at first, but I highly suggest anyone that writes blog posts in markdown to check it out.
http://madoko.codeplex.com/
http://research.microsoft.com/en-us/um/people/daan/madoko/do...
From the reference:
> Instead of a plethora of backends, Madoko concentrates on generating either HTML or high-quality PDF files through LaTeX. There has been a lot of effort in Madoko to make the LaTeX generation robust and customizable while integrating well with the various academic document- and bibliography styles. This makes it possible to write articles using just Madoko and get both a high-quality print format (PDF) and a great looking HTML page.
[1] https://github.com/benweet/stackedit/