Latex support

[Francisco Santos]

Hi 👋, me and my friend @zazedd want to add support for LaTeX.
Basically, we want to extend the project so that the lexer can read the LaTeX option (the idea is to add a new lexer file).
We want the LaTeX option to work as the Markdown one seamlessly, when reading a .tex file the lexer to be used is the one we would implement.

Thanks for taking the time to read this issue and for this amazing project.

[Marek Kubica]

I assume that should be pretty much doable, you'd need to parse out the blocks that you want to support (e.g. minted). However, parsing LaTeX properly might not be an easy feat but most likely also not necessary for what you want to do so it should be fine.

Adding new formats is reasonably easy so I'd say go for it!

[Leonardo Santos]

Sorry for the inactivity. We have had a "beta" version for quite some time, and we made some decisions we would like to ask your opinion about.

The LaTeX lexer is defined in a new file, as to separate it from the Markdown one. We chose to do it this way because the user might, just as I'm doing later in this post, write LaTeX inside Markdown or vice versa and use syntax that mdx will then lex as if we were inside a LaTeX file.

LaTeX doesn't have code listings by default, so we assume the user has defined an environment for OCaml code and the mdx-errors, each called ocaml and mdx-errors respectively, for example:

% LSTLISTING

\usepackage{listings}

\lstnewenvironment{ocaml}
  {\lstset{language=[Objective]Caml}}
  {} % styling

\lstnewenvironment{mdx-error}
  {\lstset{language=[Objective]Caml}}
  {} % styling

% MINTED

\usepackage{minted}

\newminted[ocaml]{ocaml}{
  % styling
}

\newminted[mdx-error]{ocaml}{
  % styling
}

The cmt labels are defined above the code listing in a comment, and the legacy labels are put inside square brackets after the \begin, like so:

% $MDX file=any_file.txt
\begin{ocaml}[version=4.14]
...
\end{ocaml}

We aren't sure if putting the legacy labels in square brackets like this is a good idea, as the user might want to, for example, define some specific style for this environment using the square brackets and they will get parsed to mdx this way.

We also haven't implemented the tests yet, but we are working on it.
I am again sorry for the delay and inactivity around this issue, we are hoping to finish it soon.

[Marek Kubica]

We aren't sure if putting the legacy labels in square brackets like this is a good idea, as the user might want to, for example, define some specific style for this environment using the square brackets and they will get parsed to mdx this way.

I would say this is a bad idea, it might indeed cause issues if the user wants to put arguments to the environment as well: e.g. when the environment options and the mdx labels conflict. In general these are "legacy" labels, so I think it is perfectly fine to not implement them in a new parser, as there are no existing LaTeX files that would be using them so no need to preserve compatibility.

Wrt to the listings, I think the ocaml environment is a good idea. In addition it could make sense to implement parsing start/end markers for typical code listing environments as lstlisting or minted (these can be hard-coded I think as there isn't all that much churn in the packages and if we need to add a new one, we can do so in a future MDX release), so the user needs to do less setup upfront.

[Leonardo Santos]

I would say this is a bad idea, it might indeed cause issues if the user wants to put arguments to the environment as well: e.g. when the environment options and the mdx labels conflict. In general these are "legacy" labels, so I think it is perfectly fine to not implement them in a new parser, as there are no existing LaTeX files that would be using them so no need to preserve compatibility.

We have fixed this, now only the normal mdx labels work.

Wrt to the listings, I think the ocaml environment is a good idea. In addition it could make sense to implement parsing start/end markers for typical code listing environments as lstlisting or minted (these can be hard-coded I think as there isn't all that much churn in the packages and if we need to add a new one, we can do so in a future MDX release), so the user needs to do less setup upfront.

If we understand correctly, the idea would be to try to parse \usepackage{minted} or \usepackage{lstlisting} , and if we are successful then create environments for the user depending on which package was imported. I personally don't agree with the idea, as the user might want to create specific styles for the environments, and so the user would need to do some extra editing of the corrected file each time.
Instead we could check for a \lstset or \setminted, and if the language defined inside it is OCaml then instead of \begin{ocaml} for the code, we would accept \begin{lstlisting} or \begin{minted}.