Pourquoi nous avons créé un éditeur Markdown de plus

Chaque fois que je choisissais un éditeur Markdown, je devais renoncer à quelque chose.

Les applications pratiques pour l’édition en ligne modifiaient le fichier lors de l’enregistrement. Celles qui préservaient le fichier tel quel offraient une expérience d’édition décevante. Et celles qui proposaient de nombreuses fonctionnalités de prise de notes étaient trop lourdes, même pour ouvrir un seul document.

J’ai fini par garder deux éditeurs ouverts à la fois.

C’est pour cela que j’ai commencé à créer mote. Un éditeur qui respecte ces trois exigences à la fois.

• Masquer les symboles Markdown et permettre une édition directe
• Enregistrer exactement le fichier que j’ai écrit
• Fonctionner avec légèreté, sans moteur web

Il existe déjà beaucoup de produits capables de répondre à chacune de ces exigences séparément. Mais je n’en ai trouvé aucun qui satisfasse les trois à la fois.

Parlons de légèreté avec des chiffres

La plupart des éditeurs Markdown prenant en charge l’édition en ligne utilisent un moteur web comme WebKitGTK ou Chromium. Ils convertissent le Markdown en HTML, puis l’affichent dans un navigateur.

Cela facilite l’implémentation, mais a un coût. C’est comme si un navigateur entier était lancé à côté du document. Le nombre de processus et la consommation de mémoire augmentent, et les frappes au clavier doivent traverser plusieurs étapes.

Pourtant, rares sont les produits qui rendent ce coût public. Sur leurs pages de présentation, on ne trouve ni consommation du processeur au repos ni latence de frappe, seulement le mot « léger ».

mote procède autrement.

Nous mesurons la consommation du processeur au repos, la mémoire, la latence de frappe et le temps de démarrage, sur le même ordinateur et selon la même méthode. Les scripts de mesure et les données brutes sont également disponibles dans le dépôt. Une version qui dépasse le budget de performance fixé n’est pas publiée.

Pour les comparaisons aussi, nous n’utilisons que des valeurs mesurées au même moment. Une valeur qui n’a pas pu être mesurée n’est pas indiquée comme égale à 0 : elle est signalée comme non mesurée.

Parce que la légèreté doit être une mesure, pas une impression.

Nous ne modifions pas le fichier lors de l’enregistrement

Lorsqu’on gère des documents avec git, il arrive de tomber sur des diff étranges.

On ne modifie qu’une cellule d’un tableau, mais le commit suivant contient aussi quantité de lignes auxquelles on n’a pas touché. C’est parce que l’éditeur a réajusté les espaces ou l’alignement du tableau pendant l’enregistrement. La ligne que j’ai modifiée se retrouve mêlée aux vingt lignes modifiées par l’éditeur.

Tout le contenu ne change pas nécessairement. Certains éditeurs préservent correctement les sauts de ligne et les espaces consécutifs. Les différences apparaissent principalement dans les tableaux et leur alignement. Et la possibilité d’enregistrer les fichiers tels quels n’est pas propre à mote.

Mais j’ai tout de même considéré qu’il s’agissait d’une exigence essentielle.

Dans mote, le texte fait foi. Les octets du fichier sont placés tels quels dans le tampon, et les caractères en gras, les tableaux ou les formules sont dessinés par-dessus. Lors de l’enregistrement, le tampon est écrit tel quel sur le disque.

Même si l’affichage devient plus agréable, le fichier n’est pas modifié en secret.

Nous commençons par assurer correctement la saisie du coréen

Les désagréments subtils des éditeurs web se ressentent sous les doigts. Même si le défilement, le flou et les mouvements paraissent similaires, ils diffèrent légèrement de ceux des applications natives du système d’exploitation.

La différence est encore plus marquée lorsqu’on saisit du coréen.

Il arrive que les caractères en cours de composition se séparent, que le curseur saute ou que des saisies disparaissent en fin de ligne. Ces problèmes surviennent lorsque l’éditeur web traite les événements de composition du coréen.

Dans mote, les caractères et les effets sont dessinés directement par le système d’exploitation. La composition du coréen est elle aussi reçue directement depuis la méthode de saisie de la plateforme. En contrepartie, il faut implémenter séparément la méthode de saisie pour chaque système d’exploitation et la vérifier sur des appareils réels. Pour l’instant, Linux est pris en charge, tandis que macOS et Windows sont en cours de développement.

C’est une voie plus difficile, mais cette différence compte pour les personnes qui écrivent de longs textes.

Les personnes qui ont besoin de mote ne sont peut-être pas nombreuses.

Les développeurs qui gèrent des README et des documents de conception avec git. Les personnes qui écrivent de longs textes en coréen. Celles qui laissent leur éditeur ouvert toute la journée sur leur ordinateur portable.

Mais les raisons qui les poussent à abandonner un éditeur sont claires.

Des diff encombrés. Une saisie du coréen qui s’interrompt. Un ventilateur qui tourne sans arrêt.

Nous avons aussi décidé de ce que nous ne ferions pas

mote ne propose ni synchronisation, ni plugins, ni liens retour, ni IA, ni fonctionnalités collaboratives.

Nous ne développons pas notre propre système de synchronisation. Nous ne mettons en place ni compte ni serveur. Nous ne créons même aucun fichier de configuration supplémentaire dans le dossier des documents. Nous n’avons ajouté aucune fonctionnalité nécessitant un état qui ne puisse pas être exprimé en Markdown.

Ainsi, seuls les fichiers .md restent dans le dossier. iCloud, Syncthing ou git continuent de fonctionner tels quels, sans même avoir besoin de connaître l’existence de mote.

Nous n’ouvrons pas non plus d’API de plugins. Il suffirait qu’un seul plugin exécute un minuteur pour que notre promesse de performance puisse être rompue. En revanche, les thèmes, les extraits et les modèles d’exportation restent ouverts. Ils permettent de modifier l’apparence du résultat sans affecter les performances pendant l’édition.

Nous ne créons pas non plus de liens retour ni de vue en graphe. Ce produit n’a pas vocation à concurrencer les bases de données de notes. Nous ne prenons en charge que l’arborescence des dossiers et les liens relatifs standards.

Nous n’ajoutons pas non plus d’IA. mote ne résume pas les textes, ne les poursuit pas et ne lit pas le dossier des documents pour en envoyer le contenu à l’extérieur. Le fait qu’un éditeur n’envoie mes documents nulle part est, à mes yeux, une fonctionnalité importante.

La collaboration en temps réel n’est pas non plus prise en charge. Pour permettre l’édition collaborative, le modèle de document du serveur doit faire foi. Cela entre en conflit avec le principe consistant à préserver exactement le fichier présent sur le disque.

Entre les deux, mote a choisi le fichier.

Si vous avez besoin de l’écosystème d’Obsidian, Obsidian est un meilleur choix. Si la stabilité éprouvée de Typora compte avant tout, Typora est ce qu’il vous faut. Et la typographie d’iA Writer reste un objectif que nous devons encore chercher à atteindre.

mote n’a pas vocation à remplacer tous les éditeurs Markdown.

Ce n’est pas non plus qu’il fallait un éditeur Markdown de plus.

Il fallait un éditeur qui respecte à la fois les fichiers et les ordinateurs portables.