Not to have ugly error on compilation, we could add an exception handler, and print real error messages in a log file.

Useful to reference a part from the document.

The center environment (bloc between ((( and )))) does not work as expected.
The mdbg code from the centered bloc is considered as raw text thus I can't center my beautiful graphs easily 🌵

To be done

• Figures and captions
• {{{ … }}} block (left bracket)
• $$$ … $$$ block (non parsed latex)
• Text alignment (maybe with !!: at the begining/end of a line)
• Small capitals, highlighted and spaced style (see soul package) (maybe with syntax /sc/text/sc/, /hi/text/hi/ and /sp/text/sp/ respectively)
• Footnotes (maybe with syntax ***{text})
• Superscript and subscript text for example for "4th" (maybe with syntax ^{text})
• Colored text (maybe with syntax {color}(text) where color can be "red" or "#A82C10" (still to do))

I pushed a temporary fix in b3f83b5 by commenting the guilty lines.

To reproduce, look at the .tex generated with the following .mdbg (with a previous commit) :

\begin{figure}[h]
  \centering
    \includegraphics[width=0.7\textwidth]{assets/schema1.png}
  \caption{-}
\end{figure}

@yopox discovered a nasty bug in our current way of parsing.
As we do smth like that : for key in keys, the order of the keys in keys does matter. And it is a problem for parsing things like %*word* other things% because as * detection is done before % detection, this example string is going to be splitted according to the * character : this destroys the information of a % embracing the whole.
A solution would be to return inline_parse(left + inline_parse(inside) + right) but as clean programmers we're not going to let that happen are we ?
That's the reason why I created a new branch, in which I proposed a first draft of a code aiming at resolving the problem.
I can't test it for now

Creating graphs / anything with TikZ is a pain : specific packages must be loaded with the \usetikzlibrary command (graphs, arrows.meta, automata, etc).

We should add a command in mdbg to specify the packages to be used.

Hi,
By changing three or four lines in the code we should be able to parse LaTeX. This should be useful for example to make quick replacements like [|, |] -> [\![, ]\!].
This would mean the LaTeX formulas we enter are simplified, so couldn't necesseraly be compiled normally, in any case coudn't necesseraly render the same with a normal compiler. Should we do this ?

One of us has proposed that we sould convert line breaks from the mdbg document to '\' in LaTeX.
However, we can't put a naive re.sub(r'\n', r'\\\\\n', text)
I tried smth : http://pastebin.com/A2fzJuY0

It consists in adding a 'pseudo-line' block and parsing it like other blocks, with an appropriated function.

What do you think of it ?

While converting .md to .tex files, mdbg creates a file called .tmp.mdbg.

It doesn't suppress it, now.

It should.

Instead of making a big string ouput and then writing it in the file, we could use print to write it progressively.

We could use 2 syntaxes :

• changing os.output as describted here :

content = 'blabla' 
file = open('output.tex', 'w') # opening file
os.output = file # changing ouput of print
print(content) # writing in file
os.output = os.__output__ # back to normal

• Or, as described here :

content = 'balbla'
file = open('output.tex','w')
print(content) >>file

The inconvenient of the second method is that you have to have file in the local environnement each time you call print. The first use more powerful (= riskier) tools.

Lines beginning with multiples # inside a block code should be overlooked.

```python
# Ce code ne crée pas une matrice car l'adresse mémoire est copiée a chaque fois
l = [[0]*p]*n

The above code produces the following output :

\verb```python
\part{Ce code ne crée pas une matrice car l'adresse mémoire est copiée a chaque fois}

l = [[0]\textbf{p]}n