Éditeur markdown pour les sciences

J’ai des cours de plus de 30 pages A4 (une fois convertis en PDF) avec beaucoup ou peu d’images, pas mal de formules de maths

Ça ne pose pas de soucis parce le contenu est coupé en morceaux au niveau des titres, du coup on ne modifie qu’un morceau à la fois (sauf quand on supprimme/ajoute un titre…) et il n’y as que ce morceau qui est converti et modifié à l’affichage

donc pas de soucis de perf avec les longs fichiers (hormis à l’ouverture, comme ça convertis tous les morceaux d’un coup), à moins de ne pas utiliser de titres du tout

le but n’est clairement pas d’arriver à un LaTeX-like, mais d’avoir les fonctions qui me sont essentielles, de la manière la moins verbeuse possible. Peut-être que dans le futur ça passeras au LaTex, mais pas cette année

Pour la séparation entre l’éditeur et le moteur de rendu, c’est plutôt bien séparé en fait

node-gtk affiche un terminal virtuel (dans la moitié gauche de l’éditeur). Je lance neovim dans ce terminal virtuel, avec en argument une commande à exécuter en cas de modifs.

Comme on peut le voir sur le shéma, en cas de modifs neovim exécute simplement le fichier neovim-hook-handler.js, qui via TCP transmet les modifs à md2html/engine.js (le script qui coordonne éditeur, moteur de rendu et affichage)

Si je met une option (c’est prévu) pour utiliser d’autres éditeur, rien ne m’empêche de définir que le comportement par défaut avec tous les éditeurs c’est de surveiller les fichiers, et que pour neovim/vim exceptionnellement fonctionner comme il fonctionne actuellement

Le code est assez souple et cloisonné pour permettre de fonctionner des deux manières

Juste pour clarifier mon propos, je parle de couplage dans le code mais aussi et surtout de couplage à l’utilisation. En l’occurrence là, le couplage dans le code est peut être relativement faible, mais à l’utilisation il est encore là. C’est très bien si s’en défaire n’est pas compliqué parce que le couplage dans le code reste faible, mais c’est prévu et c’est fait sont deux choses bien différentes pour l’utilisateur. C’est le design "je branche directement mon éditeur et mon moteur ensemble pour faire du rendu temps réel" qui crée forcément un couplage fort à l’utilisation et présent quoiqu’il arrive dans le code que je critique plutôt que son implémentation effective. Si c’est bien fait et que généraliser pour affaiblir le couplage à l’usage est faisable sans trop d’efforts, c’est déjà pas mal.

Salut, c’est un peu off-topic mais disposes-tu d’une documentation de ton setup ? je suis plutôt intéressé pour en utiliser un similaire, éventuellement en intégrant zotero dans la boucle.

La "documentation" tient en ces quelques lignes. Vim dans un process, latexmk dans un autre, et un lecteur pdf capable de mettre à jour l’affiche lorsque le fichier change (en l’occurrence j’utilise evince principalement, mais la plupart font l’affaire je pense). C’est spartiate, mais redoutablement efficace et ultra-flexible.

En pratique, lorsque je veux éditer un fichier, je l’ouvre dans vim et je lance latexmk à la main dans un onglet tmux. J’ai configuré latexmk pour tourner en continu en vérifiant les modifications ($preview_continuous_mode = 1;) et ouvrir evince avec le document produit ($pdf_previewer = "start evince %O %S";) dans ~/.latexmkrc. Si c’est un projet local un peu compliqué (avec un fichier principal qui en inclue d’autres par exemple), il suffit d’avoir un .latexmkrc local approprié pour dire à latexmk lequel est le principal.

Coucou  !

Comme il avait été prévu et suggéré, le moteur de rendu est maintenant totalement indépendant de l’éditeur et de l’affichage  !

Il a du coup son propre package, ce qui permet de le ré-utiliser plus facilement dans d’autres projets !

Cela va également permettre la mise en place de tests unitaires dans le futur

J’en ai profité pour ajouter 2 micro-fonctions (plutôt remettre des fonctions que je n’avais pas recodé depuis le passage à zmarkdown ) :

• ![]() qui permet de d’aller après une image

  Si vous avec une image qui fait 50% de large, et un paragraphe qui suit, le paragraphe va être à droite de l’image. Si vous ne voulez pas ça, en insérant ![]() avant le paragraphe, celui-ci descendra sous l’image

• <------------> (avec au moins 5 -) affiche une ligne pointillée dans le rendu, et permet d’indiquer où couper à l’impression (pour l’export pdf)

  En fait ça ne coupe pas pour le moment…. mais je n’ai pas le temps d’investiguer ce soir, donc pour le moment ça fait uniquement une ligne pointillée

Du coup ça modifie (légèrement) le shéma de la stack technique :

J’en profite pour signaler son alternative ouvert (licence MIT) MarkText

Il y a un support des formules/équations chimiques dans Typora, Zetler, Joplin, et MarkText enfin, via KaTeX-mhchem : on utilise donc toujours la syntaxe maths avec la commande spéciale \ce{} https://mhchem.github.io/MathJax-mhchem/ Mais bon, ce n’est pas de la représentation de structure…