Live data from Hacker News

Reach for Markdown, not LaTeX

blog.jez.io

131–140 of 184 posts

Re: Reach for Markdown, not LaTeX

#131

Earlier quoted context omitted.

Maybe you should take a look here and disabuse yourself of that idea: https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings Relevant bit: It supports the following programming languages: ABAP2,4, ACSL, Ada4, Algol4, Ant, Assembler2,4, Awk4, bash, Basic2,4, C#5, C++4, C4, Caml4, Clean, Cobol4, Comal, csh, Delphi, Eiffel, Elan, erlang, Euphoria, Fortran4, GCL, Gnuplot, Haskell, HTML, IDL4, inform, Java4, JVMIS, ksh,…

Ah, seems like the situation is better than I remembered. I confused colored syntax highlighting with the default settings, which highlight using font weight/italicness etc. I did try minted once, but never used it in practice. The dependency on pygments making the documents more system dependent is less than ideal.

You can of course redefine the default style if you don't like it, but that is no more work than doing the equivalent in CSS (I guesS?) for whatever MD renderer one uses.

I agree that pygments adds a bunch of dependencies, which may be too much just to get some colored syntax highlighting.

Re: Reach for Markdown, not LaTeX

#132

Earlier quoted context omitted.

My problem with LaTeX is that a ton of programmers think it's a good idea to use LaTeX instead of, say, Word or Writer or plain text wrapped at 80 characters or a Wiki for things like process or project documentation. Programmers love to use LaTeX, because they get to feel like they're doing something exciting like writing a computer program when what they're actually doing something incredibly boring like writing do…

Not many go into LaTeX "loving it". Many of us try Word first, and are just unhappy with its output. If you need something that is well typeset and don't want to spend a few $10k on professional typesetting software, LaTeX fits the bill well. Everything else about LaTeX is a pain, not a joy. Is a lot of documentation written in LaTeX? I would never use it for that. Paper that is going to be submitted to a conference?…

> Is a lot of documentation written in LaTeX? I would never use it for that.

No, we have CS interns from the local college who invariably ask about it. We only have them for a few months, so I've probably answered that question several dozen times in the past few years. I know they use LaTeX for their papers as required by their CS department, so I know why we get the question. I'm just tired of answering it.

> Word is a pain if you need something other than very standard formatting.

I don't disagree with that, but our standardized formatting is to use the default styles. Use Title for the doc title, use Heading 1 for each major step or process if the doc has more than one (most don't) and Heading 2 for each individual step. This means the Navigation Pane serves as your document navigation. Most of our docs are less than 20 pages or so (and most of that is screenshots).

Re: Reach for Markdown, not LaTeX

#133
post #130

I don't get it. Say I already know that I'll need some formulae in my document. Then the use case here seems to be, essentially, that I can write # Section Name instead of \section{Section Name} and that I can write *important stuff* instead of \emph{important stuff}. I can see that the markdown version is a little nicer on the eyes and keyboard, but only by a small margin. Now, if I write a document in latex I need…

But arch has pandoc in pacman. All you have to do is `pacman -S pandoc`

Re: Reach for Markdown, not LaTeX

#134
post #130

I don't get it. Say I already know that I'll need some formulae in my document. Then the use case here seems to be, essentially, that I can write # Section Name instead of \section{Section Name} and that I can write *important stuff* instead of \emph{important stuff}. I can see that the markdown version is a little nicer on the eyes and keyboard, but only by a small margin. Now, if I write a document in latex I need…

Pandoc is awesome for things like tables or code blocks.

Here is a table in pandoc markdown:

    | Header 1 | header 2 |
    |-|-|
    | Column 1 | Column 2 |
Which is easy to write via emacs mode/vim plugin. Similar for code blocks. Plus this is extendable, I frequently use an extension that transforms DOT syntax into embedded graphs.

Re: Reach for Markdown, not LaTeX

#135
post #134
post #130

I don't get it. Say I already know that I'll need some formulae in my document. Then the use case here seems to be, essentially, that I can write # Section Name instead of \section{Section Name} and that I can write *important stuff* instead of \emph{important stuff}. I can see that the markdown version is a little nicer on the eyes and keyboard, but only by a small margin. Now, if I write a document in latex I need…

Pandoc is awesome for things like tables or code blocks. Here is a table in pandoc markdown: | Header 1 | header 2 | |-|-| | Column 1 | Column 2 | Which is easy to write via emacs mode/vim plugin. Similar for code blocks. Plus this is extendable, I frequently use an extension that transforms DOT syntax into embedded graphs.

Thing is, if you're already looking to use e.g., Emacs, you'll be better off using org-mode instead of markdown. Same lightness of syntax, tens of times the functionality (including much better tables, which you can use directly from a TeX document, as well, via radio tables).

Editing ascii tables with no editor support is painful.

There's also some org functionality in vim plugins, though I've never used them, so I don't know how much they cover.

Re: Reach for Markdown, not LaTeX

#136
post #134
post #130

I don't get it. Say I already know that I'll need some formulae in my document. Then the use case here seems to be, essentially, that I can write # Section Name instead of \section{Section Name} and that I can write *important stuff* instead of \emph{important stuff}. I can see that the markdown version is a little nicer on the eyes and keyboard, but only by a small margin. Now, if I write a document in latex I need…

Pandoc is awesome for things like tables or code blocks. Here is a table in pandoc markdown: | Header 1 | header 2 | |-|-| | Column 1 | Column 2 | Which is easy to write via emacs mode/vim plugin. Similar for code blocks. Plus this is extendable, I frequently use an extension that transforms DOT syntax into embedded graphs.

Tables are very complicated in LaTeX... but for a goodreason: tables are just hard. In your example:

- Should the table appear flushed to the left? Centered in the page? flushed to the right? Full-width or only content-width?

- What happens when Column 1 is long? Should the text wrap inside its own cell, overflow, or what?

- Which row/column lines should appear? None? All of them? Only those that separate headers?

These matters will only get more complicated once the table starts growing.

Of course, you could say that all these issues are presentational, and hence it's your theme's job to handle, not yours. That is fine until it breaks and you need to fix it though...

Code blocks are very easy in latex too. Install the "minted" [1] package and you can just:

  \begin{minted}[python]
    def something():
      ...
  \end{minted}
About extensions, it depends I suppose. In your case I would use some rendering app like graphviz and just \includegraphics the resulting ps/pdf. All this can be easily scripted (if you are able to create an extension you should have no problem writing a script that rebuilds your ps/pdf files before building the latex file).

I do think that writing simple files in markdown feels better than doing it LaTeX. Unfortunately, as the document starts getting more complicated it's always been easier for me to just turn to "pure" LaTeX than to try and deal with it through pandoc extensions.

[1] https://github.com/gpoore/minted

Re: Reach for Markdown, not LaTeX

#137

Earlier quoted context omitted.

I wrote my math phd thesis in Markdown/LaTeX in this way. I also replaced all maths symbols with their Unicode equivalent. The result was very readable markdown source text, easily compiled to Latex and PDF, using a mk file. My thesis also included formalised proofs in a proof assistant, and they were just written straight into the markdown files as code blocks, and were using the same Unicode symbols as the rest. La…

I wrote mine in plain LaTeX, never had an issue with it. Regarding code, you can use the listings package (\lstincludelisting) to include source code files directly. I fail to see the interest in having a bastardized, not quite TeX, not quite MD file (unless you're using something like Org, of course, and using its other functionalities). Regarding having unicode for the maths, how did you deal with symbols that need…

I just make the symbols shortcuts for the commands. So for instance

∑_{0≤n≤k}n²

expands to

\sum_{0\le n\le k} n^2.

Re: Reach for Markdown, not LaTeX

#138

Earlier quoted context omitted.

Wow, this is just so far off the mark I don't even know where to begin. LaTeX excels in three areas that are crucial for writing complex documents -- cross references, citations, and indexing. You clearly have not had to endure the house of horrors that is the MS Word ToC, or trying to get autonumbering working as you wish for sections, figures, and tables, or managing a large (100s of pages) multipart document, or a…

You don't know the requirements of documentation that we're writing. They don't need a table of contents. They don't need an index. They don't need citations. They don't need math symbols. They don't need tables more complex than a word processor can create. We require no features which your typical academic or research paper requires. We are documenting processes with screenshots that users can refer to in order to…

> You don't know the requirements of documentation that we're writing

Yet you seem happy to prescribe your (extremely limited) views on everyone else without knowing their situation.

Good for you if all your documentation requirements are trivial, and I'm sorry to hear that your team cannot cope with trivial software installs or simple markup. Maybe the problems lie not with LaTeX...

Re: Reach for Markdown, not LaTeX

#139
post #130

I don't get it. Say I already know that I'll need some formulae in my document. Then the use case here seems to be, essentially, that I can write # Section Name instead of \section{Section Name} and that I can write *important stuff* instead of \emph{important stuff}. I can see that the markdown version is a little nicer on the eyes and keyboard, but only by a small margin. Now, if I write a document in latex I need…

But arch has pandoc in pacman. All you have to do is `pacman -S pandoc`

Right, but look at its dependencies. Arch links haskell packages dynamically, so you easily end up in DLL hell.

Re: Reach for Markdown, not LaTeX

#140

Earlier quoted context omitted.

I'd also add that while Markdown and LaTeX can do some of the same things, they're designed toward very different tasks. I've used both numerous times in my career, and I can't remember a case where it's been ambiguous which tool was more appropriate for the task. If it's going to be printed, you probably want LaTeX. If it's going to be rendered to a screen, you probably want Markdown. If it's going to be rendered to…

Why is LaTeX unambiguously better for print? Is it just the support for math notation, or is there more to it? And since "print" very often means a PDF that's also available online, has there been any progress on tagged PDF support in pdflatex or a similar tool? This is important for accessibility.

Aside from what other commenters told you: LaTeX just typesets better, meaning that it will choose line-breaks, inter-character and inter-word spacing, ligatures, hyphenation, etc. much better than your regular browser.

Try justifying text on a relatively narrow column in HTML, and then try it with LaTeX. There's a world of difference in readability between them.

Post reply on HN