DME

La force du Markdown est son minimalisme. Il commence à poser problème lors du partage d'un document en PDF pour assurer un haut niveau de qualité. L'affichage du code est souvent sous optimale. Pour changer la mise en page, la seule solution est d'écrire du CSS pure.

Et si l'expérience de rédaction minimaliste était augmenté pour simplifier l'export, la navigation et le surlignage du code ?

Le défi du code

Il y a une grande différence de qualité entre du code surligné et du code très bien surgligné. La différence ne se trouve pas dans le thème choisi, mais dans la manière qu'ont les différents outils de découper les tokens (morceaux) du code et la type de token attribué.

Si on prend un extrait de Rust #[error("This content is not associated to any valid key.\nHint: maybe this [...]")] il existe plusieurs manière de la découper:

• Une forme naive: #[error( , " ,This content is not associated to any valid key.\nHint: maybe this [...] ,",)]
• Une forme avancée: #,[ , error , ( , " ,This content is not associated to any valid key.,\n, Hint: maybe this [...] ,",),]

La clé est dans le nombre de token et dans le type attribué. Un thème ne peut indiquer une nuance sur la différence syntaxique entre # et error, seulement si les tokens sont séparés et ont un type différent.

Le surlignage du code n'est pas ouf

Regardons un exemple plus complet de Rust pour comparer les outils. Prenons d'abord le rendu de Markdown PDF, qui utilise HighlightJS. Le rendu est acceptable mais plusieurs petits problèmes ressortent.

• la variante ContentOutOfKey de l'enum devrait être colorisée comme les autres (comme DuplicatedKey).
• self est une variable et Self est un type, ils devraient être de couleurs différentes.
• La structure ParseError devrait avoir ses attributs range et error colorisés. Les types de ces attributs Range et ParseErrorType manquent aussi de colorisation.
• Pour std::cmp::Ordering la hiéarchie de module std::cmp:: devrait être colorisé différent que le type Ordering

Prenons le rendu de Typst, qui utilise les syntaxes Sublime Text. Le rendu est encore moins qualitatif.

• Toutes les variantes de l'enum devraient avoir une couleur dédiée
• PartialOrd est une type qui devrait être surligné comme tel (comme ParseError)
• Commentaire dupliqué pour std::cmp::Ordering et la structure ParseError

Prenons le rendu de VSCode et Shiki qui utilisent les grammaires TextMate. Le rendu est presque parfait...

• On note la colorisation du if et else mais les numéros 1 et 0 ne le sont pas...
• La variante ContentOutOfKey de l'enum devrait être colorisée comme les autres (comme DuplicatedKey).
• Le problème du self différent de Self revient ici.

L'approche de DME

DME utilise Tree-Sitter pour atteindre une qualité maximum de rendu. Cette technologie est intégrée à Neovim et Zed (et bientôt VSCode).

Tous les problèmes relevés précédemment sont résolus. On note même certaines nuances syntaxiques avancées:

• Le error et derive ont une couleur commune et différente du reste de l'expression.
• Les tokens # ont un type différent que [ ] ( )
• Le self étant une variable particulière, elle est très légèrement plus rouge que une variable normale comme other.

Le défi des maths

Les maths en Latex ça détruit nos touches backslash

Déjà écrit une matrice en Latex ? Ca te fait pas mal au cibolot rien que d'y penser ?

Pour afficher ce genre d'équation...

$$
\begin{pmatrix} a_1 \\ a_2 \\ a_3 \end{pmatrix}
\wedge
\begin{pmatrix} b_1 \\b_2 \\ b_3 \end{pmatrix}
=\begin{pmatrix} 
\begin{vmatrix} a_2 & b_2 \\ a_3 & b_3 \end{vmatrix} \\
- \begin{vmatrix} a_1 & b_1 \\ a_3 & b_3 \end{vmatrix} \\
\begin{vmatrix} a_1 & b_1 \\ a_2 & b_2 \end{vmatrix} \\  
\end{pmatrix}
$$

ou la version Typst ?

$$
vec(a_1, a_2,a_3)
and
vec(b_1,b_2,b_3)
= mat(
&mat(delim: "|", a_2, b_2; a_3, b_3);
-&mat(delim: "|", a_1, b_1; a_3, b_3);
&mat(delim: "|", a_1, b_1; a_2, b_2);
)
$$

Le défi de l'export

Comment j'exporte mon document vers un PDF joli ?

Tu as déjà essayé de trouver un bon plugin d'export dans VSCode ? Le plus connu est Markdown PDF qui a commencé en aout 2016, et le nombre de variantes démontre que les gens ne sont pas satisfaits de cette solution.

Tu te fais des résumés et tu veux réduire toutes les tailles de mise en page pour que tout le contenu rentre sur quelques pages ? Il va falloir écrire du CSS manuel. Le preview de l'IDE n'est souvent pas le même que celui de l'export. Cela force des exports réguliers pour voir le rendu final des changements de style...

L'export PDF de DME

Une seule touche E pour exporter le document ouvert en PDF. Une interface pour changer le style visuellement dans DME avec des boutons et sliders. Au lieu d'exporter en PDF pour tester le rendu final, le rendu de DME est presque identique à celui de l'export final et peut être ajusté avec feedback immédiat.

Imagine pouvoir changer dans l'interface graphique la taille des titres, des marges, des espaces entre titres, paragraphes et images, bouger les images au centre ou à droite. Mettre 2 images l'un à coté de l'autre ou encore définir 2-3 colonnes automatiques.

TODO: implémenter et documenter cette expérience

Installation

Voir la page suivante pour l'installation !