Pandoc Markdown and ReST Compared (2013) • Hacker News Board

Re: Pandoc Markdown and ReST Compared (2013)

#21

Post by Turing_Machine » Sat, Mar 08, 2014, 10:05 PM UTC

balladeer wrote: post #18

Pandoc and ReST are extensive, flexible, and simply complete. They are great. I have never understood the fetish behind Markdown and the cult-like fan-boyish approach to it. It was not needed. It would have been rather good to standardised an existing markup (or a combination of them) than copy the existing one and pretty much release it with a different name.

" I have never understood the fetish behind Markdown"

For one, there are multiple (and good) implementations of Markdown in Javascript, so it's trivial to embed Markdown in web pages and do all the processing client-side -> faster and better user experience + much lower server load.

Pandoc a) only runs locally/server-side and b) requires a 200 MB Haskell install before it will work.

Re: Pandoc Markdown and ReST Compared (2013)

#22

Post by teleclimber » Sat, Mar 08, 2014, 10:11 PM UTC

gkya wrote: post #15

teleclimber wrote: post #7

Am I the only one who feels like they were teleported back to the early 1990s upon seeing these text files with code intermingled everywhere? I am not bashing markdown and friends, as I understand there is a use for these tools in some cases, but I am surprised they are so widely embraced and loved. To me they just evoke the days of typing an essay on dad's 386 with Word Perfect 5.1 installed, and having to hit "reve…

Most the tools we have for WYSIWYG document creation lacks determinism and portability . For the latter, one could argue that there are open formats, but still, there should be a program that can interpret the format; whereas with plain text, such a need is void, as it is possible to view the document on any decent system. For the former, the argument might be that the modern word processors provide the facilities to…

I agree with what you said. I understand the advantages of markdown and why it is adopted (particularly in dev environments).

But you seem to agree with me that the markdown editing experience leaves a little to be desired ("...I happily trade editing convenience off").

What I don't get is why that editing experience doesn't annoy people more. There are tons of markdown-powered blogging platforms, editors, commenting forms coming out every day, but you almost never see projects that try to solve the original problem.

Re: Pandoc Markdown and ReST Compared (2013)

#23

Post by gkya » Sat, Mar 08, 2014, 10:37 PM UTC

teleclimber wrote: post #22

gkya wrote: post #15

Earlier quoted context omitted.

Most the tools we have for WYSIWYG document creation lacks determinism and portability . For the latter, one could argue that there are open formats, but still, there should be a program that can interpret the format; whereas with plain text, such a need is void, as it is possible to view the document on any decent system. For the former, the argument might be that the modern word processors provide the facilities to…

I agree with what you said. I understand the advantages of markdown and why it is adopted (particularly in dev environments). But you seem to agree with me that the markdown editing experience leaves a little to be desired ("...I happily trade editing convenience off"). What I don't get is why that editing experience doesn't annoy people more. There are tons of markdown-powered blogging platforms, editors, commenting…

Desirability of the editing experience is a function of the kind of editing one does: I mostly write text-heavy stuff, blog posts, README's and similar stuff. For these stuff, I am quite happy with markdown, vim and the general workflow of mine around these tools; and I like that workflow. I do not need a piece of text to be red, or be centred, or wrapped around an image. Still, me and alike are the minority; normal people want these kinds of stuff.

For instance, I've deployed (!) a couple WordPress blogs and a PhpBB forum for a friend (yes, I'd touch none of these for my projects). When it was time to test-post in the forum, I started explaining him the markup for PhpBB. His reaction was this: "But in vBulletin, there is a text editor. I think I'll pay them $400 for that." He wants to centre the text, and emphasise phrases via colouring them red. Because he can. He is a normal person.

While I like my workflow, with markdown, vim, and a static site generator; I do not find markdown and alike useful for any major inscription, e.g. papers and books and alike. I'd rather use a suitable tool that takes away the burden of manually writing the markup, and allow me to focus on content for such work. iA Writer makes me horny, but unfortunately I do not own a Mac. I admit that I'd go nuts should I need to write a book in, say, LaTeX (or however it is spelled). Yet, the problem of portability of files is a superior problem than lack of convenience while editing. If I write my book with iA, and if it goes next year, what'll I do?

Re: Pandoc Markdown and ReST Compared (2013)

#24

Post by bowerbird » Sun, Mar 09, 2014, 12:32 AM UTC

teleclimber wrote: post #22

gkya wrote: post #15

Earlier quoted context omitted.

Most the tools we have for WYSIWYG document creation lacks determinism and portability . For the latter, one could argue that there are open formats, but still, there should be a program that can interpret the format; whereas with plain text, such a need is void, as it is possible to view the document on any decent system. For the former, the argument might be that the modern word processors provide the facilities to…

I agree with what you said. I understand the advantages of markdown and why it is adopted (particularly in dev environments). But you seem to agree with me that the markdown editing experience leaves a little to be desired ("...I happily trade editing convenience off"). What I don't get is why that editing experience doesn't annoy people more. There are tons of markdown-powered blogging platforms, editors, commenting…

my intention is to solve the problems, all of them.

so i would appreciate a thoughtful write-up of them. i know many of them, probably most. but i'm curious.

my target is writers, not programmers, but my intent is to create the best possible tool for those writers. not just a "suitable" tool -- the _best_one_possible_.

-bowerbird

Re: Pandoc Markdown and ReST Compared (2013)

#25

Post by teleclimber » Sun, Mar 09, 2014, 4:03 AM UTC

gkya wrote: post #23

teleclimber wrote: post #22

Earlier quoted context omitted.

I agree with what you said. I understand the advantages of markdown and why it is adopted (particularly in dev environments). But you seem to agree with me that the markdown editing experience leaves a little to be desired ("...I happily trade editing convenience off"). What I don't get is why that editing experience doesn't annoy people more. There are tons of markdown-powered blogging platforms, editors, commenting…

Desirability of the editing experience is a function of the kind of editing one does: I mostly write text-heavy stuff, blog posts, README's and similar stuff. For these stuff, I am quite happy with markdown, vim and the general workflow of mine around these tools; and I like that workflow. I do not need a piece of text to be red, or be centred, or wrapped around an image. Still, me and alike are the minority; normal…

Thank-you for the thoughtful response.

Yes, clearly the markdown thing is natural for developers. After all devs spend all their time in cryptic text files that get transformed into something more useful and beautiful That's their (our) thing.

And since developers are the ones who create forum software, blogging platforms, one can only expect that their personal preferences would bleed over into these projects.

But it's unfortunate because in the meantime we're not really advancing the art of editing content, which is something the "normals" would appreciate. (And I think even a number of developer-types would appreciate writing content without markdown if you gave them something that actually worked and worked with static site generators.)

Regarding IA, I don't have it but it says that it saves files as plain text?

Re: Pandoc Markdown and ReST Compared (2013)

#26

Post by bowerbird » Sun, Mar 09, 2014, 5:19 AM UTC

teleclimber wrote: post #25

gkya wrote: post #23

Earlier quoted context omitted.

Desirability of the editing experience is a function of the kind of editing one does: I mostly write text-heavy stuff, blog posts, README's and similar stuff. For these stuff, I am quite happy with markdown, vim and the general workflow of mine around these tools; and I like that workflow. I do not need a piece of text to be red, or be centred, or wrapped around an image. Still, me and alike are the minority; normal…

Thank-you for the thoughtful response. Yes, clearly the markdown thing is natural for developers. After all devs spend all their time in cryptic text files that get transformed into something more useful and beautiful That's their (our) thing. And since developers are the ones who create forum software, blogging platforms, one can only expect that their personal preferences would bleed over into these projects. But i…

let me try again.

if you have _specifics_ on "the art of editing content", and the interface you want, i would like to hear them...

-bowerbird

Re: Pandoc Markdown and ReST Compared (2013)

#27

Post by prairiedock » Mon, Mar 10, 2014, 5:11 PM UTC

bowerbird wrote: post #11

i am in the process of releasing "zen markup language". it's "lighter" than all the other light-markup languages. it's more _powerful_ than the others, including asciidoc. it's also far more agile, and much easier to understand. and i won't allow it to be fragmented, like markdown is. i've coded converters in javascript and other languages. the javascript minimizes well for inclusion in web-pages. i have cross-plat a…

I Looked at the site for z.m.l (http://www.z-m-l.com/). It doesn't seem to do math, so it's a nonstarter.

BTW, Pandoc (which does do LaTeX math) really needs no improvement, only more widespread implementation (e.g., an online site, and/or a chrome extension coded in javascript.) I suppose its being written in Haskell has been an impediment.