Live data from Hacker News

Thoughts on Markdown

smashingmagazine.com

71–80 of 167 posts

Re: Thoughts on Markdown

#71
post #40

Earlier quoted context omitted.

> "LaTeX gets the content and fits to the constraints at hand" I'll believe this when scientific papers start appearing in the form of reflowable HTML.

> I'll believe this when scientific papers start appearing in the form of reflowable HTML. YES! It's 2022 and in spite of the often-praised superiority of LaTeX, we are still getting paginated PDFs on ArXiv, instead of responsive text that reflows on different screen sizes. PDFs were great to read when I was still printing papers. For reading on screen they are quite inconvenient. Many publishers have come around in…

> It's 2022 and in spite of the often-praised superiority of LaTeX, we are still getting paginated PDFs on ArXiv, instead of responsive text that reflows on different screen sizes.

It's not about LaTeX per se. You can typeset EPUBs with it too, if you want. So reflow ability is not a shortcoming of LaTeX.

Publishers send you a Word or LaTeX template, and require your manuscript as a PDF, conforming to that template. If it's LaTeX, generally there's a switch to render the text in "Review mode" with line numbers and similar additional details, and omitting author data if the judgement will be done blindly.

So, the tool itself, regardless of its brand is the proverbial wrong tree to fight with. Also, it's a reality that reading a 25 page manuscript is not very efficient on a screen, at least in my discipline. I have a dedicated "Paper printer" at home for printing such manuscripts and taking a stab at it with pens and highlighters.

Re: Thoughts on Markdown

#72

Earlier quoted context omitted.

> Markdown is lovely for tech documentation That’s one of the weakest points of Markdown, because it has no support for any sort of cross-referencing so they have to be maintained by hand or through bespoke extension (often conflicting).

MySt and sphinx are getting attentions these days. As a ascii doc lurker, and fed up of rst, I'm very hopeful.

Sphinx & rst combo is great in theory. in practice, it has a big learning curve and the python tooling is not the fastest option. I had tried it once in my previous job, and people do not want to learn it, or spend time with doc related stuff

That makes me appreciate markdown a lot, As it is easier to pick up. And has fantastic tooling. And there is at least one md to html project, which will be in your language of choice

Re: Thoughts on Markdown

#73

>That’s almost 20 years ago — yikes! What started as a more writer- and reader-friendly syntax for HTML The author appears to have some recency bias that misses the point of Markdown. It didn't start when it was named and mapped to HTML. It was in use on usenet and in emails before HTML even existed. And most of its conventions came from typewriters before that. You could print out a Markdown document today and jump…

The author is also a Sanity employee and, while I like the ideas behind the Sanity CMS, if you ever create a schema with an RTF field, you'll see the opposite extreme when you read the text back via GraphQL. If Markdown was created to make the source readable, Sanity exists to make content unreadable (via expansive nested JSON for even simple tags like ). It's pretty easy for a paragraph of text to take 200 lines of Sanity JSON.

Like Sanity, this author has expanded three paragraphs of content into 600 lines of text. I'm an avid reader but that doesn't mean I want to reread the same reworded premise over and over.

Re: Thoughts on Markdown

#74
post #59
post #53

We have a binary and universal format for plain text (utf8) that is extended all the time with additional emojis. But it seems almost unimaginable that we ever get a binary text format that also allows simple semantic markup, like emphasis, tables, hyperlinks, amounts, dates, and phone numbers. It's 2022, and really, we should be able to copy a paragraph from an email with a table in it into a chat app and have it ju…

Well, that really seems to be a very hard problem to me. Tables for instance get quite complex pretty fast -- joined cells, text alignment, etc. As for a format which -- not plain text, though -- that handles this is rich text. It's been around for quite some time. IMHO the problem is in the difference between presentation and data. One group of consumers want the "data" and parse it, the other group of consumers wan…

Tables can be arbitrarily complex, just like html, so yes a line has to be drawn somewhere. Spreadsheets and slide presentations can be copy-pasted as file attachments. That's fine.

You can't have a table look the same in every app, nor is that desirable (you'd have to embed fonts and re-create postscript). What you can have is the ability to copy-paste a table (or a bulleted list) back and forth between apps without mangling the state in the process. Rich Text intertwines semantics and style and it's not a good solution.

Most of the time you don't need the layout precision of postscript. There is a huge difference between not having any kind of tables or semantic context for text and having some that cover the 95% of daily use.

Re: Thoughts on Markdown

#75
post #72

Earlier quoted context omitted.

MySt and sphinx are getting attentions these days. As a ascii doc lurker, and fed up of rst, I'm very hopeful.

Sphinx & rst combo is great in theory. in practice, it has a big learning curve and the python tooling is not the fastest option. I had tried it once in my previous job, and people do not want to learn it, or spend time with doc related stuff That makes me appreciate markdown a lot, As it is easier to pick up. And has fantastic tooling. And there is at least one md to html project, which will be in your language of c…

Yeah rST is theoretically nice but being both permissive and extremely whitespace-sensitive makes it very fiddly in practice, with inscrutable warnings and many mis-compiled documents with no warnings or information.

Some of the markup choices were really less than ideal in retrospect, especially indentation for quoting and definition lists (though it’s nice to have definition lists), even more so given the aforementioned whitespace sensitivity.

Really hard to beat as a thing to build around, but that also greatly limits the ability to process or reimplement it.

Re: Thoughts on Markdown

#77
I'm wondering that the article doesn't mention AsciiDoc with a single word. AsciiDoc is a perfect tool for complex text documents with tables, references, side notes etc. It is almost as easy as Markdown (if you compare only the features included in both), but offers way more possibilities. There are also good tools to convert it to different output formats like HTML and PDF.

A good starting point is: https://asciidoctor.org/

Re: Thoughts on Markdown

#78
post #41

appreciate a lot of the points made in the post but ``` distinct( *["code" in body[]._type] .body[_type == "code"] .language ) ``` is "trivial" for no human being

Your content editors would never write that. But if they asked for a feature where you can filter content by programming languages, GROQ would allow your engineers to build it very quickly.

I think it was probably a mistake for the article to go into GROQ, but the essence of the point is that content as structured data means content is queryable.

Re: Thoughts on Markdown

#79
post #72

Earlier quoted context omitted.

MySt and sphinx are getting attentions these days. As a ascii doc lurker, and fed up of rst, I'm very hopeful.

Sphinx & rst combo is great in theory. in practice, it has a big learning curve and the python tooling is not the fastest option. I had tried it once in my previous job, and people do not want to learn it, or spend time with doc related stuff That makes me appreciate markdown a lot, As it is easier to pick up. And has fantastic tooling. And there is at least one md to html project, which will be in your language of c…

Hence MyST.

Re: Thoughts on Markdown

#80
post #30

Earlier quoted context omitted.

Using Markdown with pandoc and pandoc-crossref is basically perfect as a substitute of LaTeX. It allows in-line and standalone LaTeX, and citations with crossref.

Are there any tutorials you could recommend please?

The official manual is pretty complete: https://pandoc.org/MANUAL.html.
Post reply on HN