MarkdownEditing – Markdown package for Sublime Text
sublime.wbond.net
sublime.wbond.net
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://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.
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 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.
I've already created an Atom package that runs that on save:
* this* isn't any easier than <i>this</i> to me.
Of course, I may be biased.
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.
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.
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.
...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.
<p>...</p>
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.
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.