Perché abbiamo creato un altro editor Markdown

Ogni volta che sceglievo un editor Markdown, dovevo rinunciare a qualcosa.

Le app comode per la modifica inline alteravano il file al momento del salvataggio. Quelle che conservavano il file così com’era lasciavano a desiderare nell’esperienza di modifica. Le app ricche di funzioni per le note erano pesanti persino per aprire un solo documento.

Alla fine tenevo aperti due editor alla volta.

Per questo ho iniziato a creare mote. È un editor che rispetta tutte e tre queste condizioni.

• Nascondere i simboli Markdown e consentire la modifica diretta
• Salvare il file che ho scritto esattamente così com’è
• Funzionare in modo leggero senza un motore web

Esistono già molti prodotti che riescono a fare ciascuna di queste cose. Ma non ne ho trovato nessuno che le soddisfacesse tutte e tre contemporaneamente.

Parliamo di leggerezza con i numeri

La maggior parte degli editor Markdown che supportano la modifica inline usa un motore web come WebKitGTK o Chromium. Convertono il Markdown in HTML e lo visualizzano in un browser.

L’implementazione diventa più semplice, ma ha un costo. È come avere un browser aperto accanto al documento. Aumentano i processi e l’uso della memoria, e anche la pressione di un tasto deve attraversare diversi passaggi.

Eppure sono pochi i prodotti che rendono pubblico questo costo. Sulle pagine dei prodotti, al posto dei dati sull’utilizzo della CPU in stato di inattività o sulla latenza dell’input da tastiera, rimane soltanto la parola «leggero».

mote fa diversamente.

Misuriamo l’utilizzo della CPU in stato di inattività, la memoria, la latenza dell’input da tastiera e il tempo di avvio sullo stesso computer e con lo stesso metodo. Anche gli script di misurazione e i dati grezzi si trovano nel repository. Non pubblichiamo build che superano il budget prestazionale stabilito.

Anche nei confronti usiamo soltanto valori misurati nello stesso momento. I valori che non siamo riusciti a misurare non vengono indicati come 0, ma segnalati come non misurati.

Perché la leggerezza deve essere un valore misurato, non una sensazione.

Non modifichiamo il file durante il salvataggio

Quando si gestiscono documenti con git, a volte capita di imbattersi in diff strani.

Hai modificato una sola cella di una tabella, ma nel commit successivo compaiono moltissime righe che non hai toccato. Questo accade perché, durante il salvataggio, l’editor ha risistemato gli spazi o l’allineamento della tabella. La riga modificata da te finisce così mescolata con le venti righe modificate dall’editor.

Non cambia necessariamente tutto il contenuto. Esistono anche editor che conservano bene le interruzioni di riga o gli spazi consecutivi. Le differenze si presentano soprattutto nelle tabelle e nell’allineamento. E la possibilità di salvare un file così com’è non è un’esclusiva di mote.

Ho comunque ritenuto che fosse una condizione da rispettare assolutamente.

In mote, il testo è il riferimento. I byte del file vengono inseriti così come sono nel buffer, mentre il testo in grassetto, le tabelle e le formule vengono disegnati sopra di esso. Al momento del salvataggio, il buffer viene scritto sul disco senza modifiche.

Anche se lo schermo cambia per diventare più gradevole, il file non viene modificato di nascosto.

Cominciamo facendo funzionare bene l’input coreano

I sottili disagi degli editor basati sul web si percepiscono sotto le dita. Anche se lo scorrimento, la sfocatura e i movimenti sembrano simili, differiscono sempre un po’ dalle app native del sistema operativo.

Quando si scrive in coreano, la differenza diventa ancora più evidente.

Può capitare che i caratteri in fase di composizione si separino, che il cursore salti o che l’input venga perso alla fine di una riga. Sono problemi che emergono mentre l’editor web gestisce gli eventi di composizione del coreano.

In mote abbiamo fatto in modo che siano i sistemi operativi a disegnare direttamente i caratteri e gli effetti. Anche la composizione del coreano viene ricevuta direttamente dal metodo di input della piattaforma. In compenso, dobbiamo implementare separatamente il metodo di input per ogni sistema operativo e verificarlo su dispositivi reali. Al momento è disponibile Linux, mentre macOS e Windows sono in fase di sviluppo.

È una strada più difficile, ma per chi scrive testi lunghi questa differenza è importante.

Forse le persone che hanno bisogno di mote non sono molte.

Sviluppatori che gestiscono README e documenti di progettazione con git. Persone che scrivono testi lunghi in coreano. Persone che tengono l’editor aperto tutto il giorno sul portatile.

Ma i motivi per cui abbandonano un editor sono chiari.

Diff disordinati. Input coreano che si interrompe. Ventole che girano in continuazione.

Abbiamo anche deciso cosa non fare

mote non offre sincronizzazione, plugin, backlink, IA né funzionalità di collaborazione.

Non creeremo un sistema di sincronizzazione proprietario. Non ci saranno né account né server. Non creeremo nemmeno un file di configurazione separato nella cartella dei documenti. Non abbiamo incluso funzionalità che richiedono uno stato impossibile da esprimere in Markdown.

Perciò nella cartella rimangono soltanto i file .md. iCloud, Syncthing e git funzionano come sempre, anche senza sapere che mote esiste.

Non apriremo nemmeno un’API per i plugin. Perché anche l’esecuzione di un solo timer da parte di un plugin potrebbe infrangere la promessa sulle prestazioni. Lasceremo invece aperti i temi, gli snippet e i modelli di esportazione. Consentono di cambiare l’aspetto del risultato senza influire sulle prestazioni durante la modifica.

Non creeremo nemmeno backlink o una vista a grafo. Perché non è un prodotto che vuole competere con i database di note. Supporteremo soltanto l’albero delle cartelle e i normali collegamenti relativi.

Non includeremo neanche l’IA. Non riassumeremo né continueremo a scrivere, e non leggeremo la cartella dei documenti per inviarne il contenuto all’esterno. Riteniamo che anche il fatto che l’editor non invii da nessuna parte i miei documenti sia una funzionalità importante.

Non supporteremo neppure la collaborazione in tempo reale. Per consentire la modifica collaborativa, il modello del documento sul server dovrebbe diventare il riferimento. Questo entrerebbe in conflitto con il principio di conservare intatto il file sul disco.

Tra le due cose, mote ha scelto il file.

Se hai bisogno dell’ecosistema di Obsidian, Obsidian è la scelta migliore. Se per te è importante la stabilità consolidata di Typora, allora Typora è la scelta giusta. Anche la tipografia di iA Writer è ancora un obiettivo che dobbiamo raggiungere.

mote non vuole sostituire tutti gli editor Markdown.

E non è neppure che servisse un altro editor Markdown.

Serviva un editor che rispettasse allo stesso tempo i file e il portatile.