Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I was wondering what prevented the implementation of a MarkDown system in (La)TeX? I know that pandoc does a conversion of MarkDown with extra features to LaTeX. I also know that many are happy with the way LaTeX is right now, so please do not feel offended.

In particular I was wondering why stuff like -> or => cannot be translated to \rightarrow or \Rightarrow and similar transformations along with the usual MarkDown features. After all to me it seems that (La)Tex after all is a way to mark-up plain text in a way that it can be rendered neatly for printing devices. I also know that there's LyX and TeXmacs but those have left the plain-text approach of tex.

In particular I'm genuine curious if and why one could not implement MarkDown features right in LaTeX, after all TeX is Turing complete, no? Does it in some way break the existing system in a way I do not see?

There's a lot that could make writing text a little more pleasant on the eyes. For example, writing a theorem like so:

THEOREM: ...

PROOF: ...


Next paragraph continues after two new lines...

and similarly for definitions lemmata, you name it. Again please don't get me wrong. There are enormous amounts of useful commands in (La)TeX. As it is now, (La)TeX does do some of these transformations already. E.g. turning --- into an em-dash or treating a blank line as the separation of two paragraphs. And modern (La)TeX can deal with unicode thus not necessarily requiring the ASCII-fication of Greek Letters. There will always be more obscure things one wants to do with (La)TeX, but what is preventing the system from incorporating features like these? Or am I missing something completely and this is possible already?

share|improve this question
3  
I am happy to see this question :). It is infeasible to get TeX to directly read a file such as what you describe and do the relevant transformations. A simpler approach, which is feasible, but still quite/very slow, is to read the file once, create a "proper" TeX file from it, and read this output to do the typesetting. I know some things already exist, and I am working on a package of my own, but it is difficult to know what is needed (and then how to code it ;-) ). –  Bruno Le Floch Feb 15 '11 at 16:40
1  
Ok, so that basically defeats the in-TeX purpose. Which would basically mean that one creates a preprocessor that transforms the document previous to feeding it to (La)TeX, which would be very close to what pandoc does. pandoc though seems to focus a lot--and that is good--on it's core idea of being a document translation tool. Otherwise I guess it's support for advanced LaTeX features would have increased more I think. –  angerman Feb 15 '11 at 16:51
    
Doesn't markdown break the separation of form and content? Does *this* mean \emph{this} or \textit{this}, for example? –  frabjous Feb 15 '11 at 20:48
    
@frabjous yes, the implicit encoding of the style to use for *this* or **this** or _this_ is something I've never been happy with with MarkDown. Still if used consistently and not tied to a specific style but merely as a markup it is a valid approach from my point of view. I think that emphasis are part of the content. How these emphasis are styled obviously not. Thus *this* turning into \emph{this} would be right I think. I'm on the edge though whether or not two different emphasis markup forms are needed. –  angerman Feb 16 '11 at 9:31
add comment

6 Answers 6

up vote 10 down vote accepted

LaTeX is this LaTeX for historical reason. It is not perfect. And it could support some MarkDown features. For example, there is a LaTeX package wiki, which support document like this:

\documentclass{article}
\usepackage{wiki}
\begin{document}
\wikimarkup

==section title==

A numbered list:
# foo
# bar
# baz

===subsection title===

''important'' thing

\end{document}

Another good example is listings package. It read the input verbatim, recognize the keywords, and make proper output. listings is designed for typeset programming languages with syntax highlighting. However, the same approach can be used for your request. So, this shows another example you request:

\documentclass{article}
\usepackage{listings}
\lstset{literate={->}{$\rightarrow$}1 {=>}{$\Rightarrow$}1}

\begin{document}

\begin{lstlisting}
a -> b, A => B
\end{lstlisting}

\end{document}

But remember, TeX, the core language is not designed for this kind of markup texts. We have to use some weird trick to implement the features in TeX.

Unlike most modern programming language, TeX uses category codes for special purpose. If TeX use a common lexical analysis, it will be easier to define a markdown system. In TeX, it is easy to define a command \THEOREM or \PROOF to typeset a theorem. But it will take much more effort (although possible) to support a syntax like

THEOREM: foo
PROOF: baz

And we can ask why Knuth choose this macro syntax. I think it is natural to use a markup language syntax, like troff, SGML and RTF. And it is clear that a pure markdown system (like stackexchange without HTML) is not powerful enough for complex style. So early TeX, which is a personal tool of Knuth, needn't support a Markdown syntax, thus the design based on category codes and macros is OK. Many people complain about this, I have no good idea for this.

Things are changing, LaTeX becomes easier to use today. For math symbol, we can use unicode-math package to write a math equation like this:

$ ∑A_n → ±∞ $
share|improve this answer
    
The problem with the unicode-math package is. Though this is not to be understood as a contradiction to the original question. That writing something like is not so easy manageable while -> can be easily types. The example of picking greek above was due to the fact that changing keyboard layout with hot keys is very easy and writing greek symbols as such is quite painless. But changing the keyboard layout to support a certain set of unicode characters, thus creating a custom keyboard layout is infeasable to me :/ –  angerman Feb 15 '11 at 16:56
2  
I think we should also bear in mind the time at which TeX was designed. A possibly small drawback like the escape character `` can make a big difference in the speed and techniques with which the source can be parsed. –  Ulrich Schwarz Feb 15 '11 at 17:55
1  
@angerman en.wikipedia.org/wiki/Compose_key I can write → just by holding the compose key and hitting -> –  Seamus Feb 15 '11 at 18:28
2  
In addition to Seamus's suggestion, a good text editor can be programmed to auto-replace certain strings with others, e.g., -> to →. E.g., in vim :iabbrev -> → or even :iabbrev -> \rightarrow if you don't want the package. (A not-so good text editor along with a text replacement program like AutoKey/AutoHotKey will also work.) –  frabjous Feb 15 '11 at 20:46
1  
@angerman: Of course, if we were to write a new typesetting system from scratch today, we might end up making different choices. Something like "as of Jan 1st, 2012, backslash becomes entirely optional" is not feasible in the given TeX ecosystem. –  Ulrich Schwarz Feb 16 '11 at 10:43
show 7 more comments

You might find this interesting (though it's for ConTeXt, not LaTeX):

https://github.com/adityam/filter

share|improve this answer
    
wasn't aware of that one. nice! now if only there were a way to make all line breaks meaningful in pandoc! –  Mica Feb 16 '11 at 0:46
    
I've seen that on the pandoc side I think. The gripes I have with pandoc are that, once it finds a tex part it just ignores, there's no way to keep using markdown with in that section. Or I'm doing it wrong and for some weird reason pandoc does not pick up lists and _..._ or **...** inside of \begin{env}...\end{env}. –  angerman Feb 16 '11 at 9:29
    
It requires external program. TeX calls VIM to do the dirty work here. –  Leo Liu Feb 16 '11 at 9:36
add comment

Here is a proof of concept solution that works in ConTeXt MkIV.

\defineenumeration[THEOREM][text={Theorem },style=italic]

\usemodule[translate]
\translateinput[THEOREM:][\THEOREM]
\translateinput[->][\rightarrow]
\enableinputtranslation

\starttext

THEOREM: Let $f : X -> Y$ be a continuous function ...

Paragram after the theorem. 

\stoptext

which gives the expected output. With LuaTeX it is possible to parse the input before it is fed to TeX, and if you want, you could write a markdown parser in lua. IIRC John MacFarlane has already written a LPEG based parser for Markdown, so it should be relatively easy to incorporate it with LuaTeX.

share|improve this answer
add comment

A wiki-like markup/down syntax is already supported by the nicetext package.

And yes, TeX is Turing (not turning) complete and can be used to implement parsers for a lot of different syntaxes. See the tikz, tikz-timing or e.g. the \Macro macro of ydoc for a few more complex examples. However, there are limits -- I wouldn't try to program an OS with it (TeXnix or so) :-)

share|improve this answer
    
thanks for pointing out the typo, fixed :) Yes I know about tikz and have used it extensively. But didn't mention it to not distract the point I was trying to make. I will definitely have a look at nicetext though. –  angerman Feb 15 '11 at 16:48
    
Turing was a person ;-). –  Bruno Le Floch Feb 15 '11 at 20:23
    
@Bruno: lol, thanks –  Martin Scharrer Feb 15 '11 at 20:25
add comment

Not really an answer to your question, but a related idea I had a long time ago: Some of the substitutions you want could be done by the editor. I once wrote an editor for LaTeX where you have a substitution table, so that you can get the following effects. If you type ->, then this is automatically converted to , but saved as \to. When \to is read from a file (or typed), you again see in the editor. Same for for \sum, ± for \pm, for \infty and so on.

The main advantage: In the editor it looks nice, and the file is plain ascii text. However, I've got no idea what editors support this feature.

Similar things would be possible for your THEOREM: ... PROOF:, but that would be less elementary to implement.

share|improve this answer
    
Yes that is true. But I'd prefere the source document to be editor independent. The conceal mode if vim does quite a bit to "tidy up" the document. To me, adding complexity to the editor to cope with structural weaknesses of the underlying system is like boilerplate code generation with annotations. It doesn't solve the problem it merely adds a cosmetic fix on top. –  angerman Feb 16 '11 at 9:26
    
@angerman: Well, the source document is then still editor independent; that's in fact my main point. It's only the appearance in the editor (i.e., the cosmetic fix) that is editor dependent. –  Hendrik Vogt Feb 16 '11 at 10:44
add comment

The problem with things like

THEOREM: ...

PROOF: ...

is, that at the point we can decide that we want special formatting here (the :), the signs before it are already typeset, and it is extremely hard for TeX (or macros written in TeX) to get these characters typed before again (to make them bold or similar).

One workaround would be to make the line-breaking character (or \par) active, and then implement a lookahead in macros (or in Lua with LuaTeX) to decide what to do next.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.