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 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.
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.
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.
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.
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.
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.
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 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/
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.
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.
"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".
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.
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.
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.
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.
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.