Éditeur markdown pour les sciences

a marqué ce sujet comme résolu.

Je ne sais pas ce que ça donne avec ton genre de contenu, mais il faut voir aussi que dès que la source est un peu longue, l’affichage ne peut pas se faire suffisamment vite. Et ce n’est pas forcément grave, compiler un programme qu’on code peut prendre du temps … pas de raison que ça soit autrement pour du texte.

Mais je pense qu’on commence à aller à l’encontre de l’esprit MD-HTML. Car typiquement ce sont des outils qui ne font pas, ou très peu, de travail typographique (pas d’empagement, pas de justification, etc.) et donc que l’intérêt du rendu est beaucoup plus bas que ce qu’on pourrait avoir avec du LaTeX.

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 ;)

+0 -0

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. :)

+2 -0

Je n’écris pas en Markdown mais plutôt en LaTeX, mais l’idée est la même. Mon workflow est le suivant, j’écris mon LaTeX dans Vim, et j’ai latexmk qui tourne en permanence en fond et recompile mon projet LaTeX dès qu’une source est modifiée (i.e. je change une image ou j’enregistre une des sources). J’ai un lecteur PDF qui m’affiche le fichier et le recharge automatiquement lorsqu’il change. Tout les éléments sont donc parfaitement découplés les uns des autres, et donc interchangeables par ce que l’on veut (typiquement, si dans un instant de folie je voulais éditer le fichier tex avec gedit, je peux et ça change strictement rien au reste puisqu’il y a zéro couplage entre les éléments). Les trois éléments (éditeur, moteur de rendu, affichage) sont trois programmes complètement indépendants, et le couplage se fait via le système de fichier.

adri1

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. :ange:

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.

+3 -0

Coucou :D !

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…. :euh: 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 :

stack technique v1.0.1
stack technique v1.0.1

Tu as jeté un coup d’œil du côté de Typora, cela fait des années que je l’utilise pour prendre mes notes de cours en MD.

Heziode

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

En revanche ce qui risque d’être embêtant pour toi, c’est qu’il ne gère pas (pour le moment en tout cas) la syntaxe SMILES.

Heziode

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…

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte