Come creare un editor che non comprometta la composizione dei caratteri coreani
Quando si scrive a lungo in hangul, può capitare che l'ultima sillaba scompaia o che una parola si spezzi. Non è un errore di battitura, ma un problema legato al punto in cui l'editor gestisce la composizione.

# appare in modo discreto, mentre i caratteri mantengono le dimensioni e lo spessore del titolo.Quando si scrive in coreano, capita di imbattersi in momenti strani. Alla fine di una riga un carattere scompare e, dopo essere passati a un'altra finestra e tornati indietro, l'ultima sillaba viene inserita due volte. A volte, durante la digitazione, il cursore si sposta anche nel posto sbagliato.
All'inizio è facile pensare che sia un proprio errore. Ma nella maggior parte dei casi non è un problema delle mani. Succede perché l'editor non gestisce correttamente la “composizione” dell'hangul.
Per inserire un singolo carattere hangul, bisogna premere più volte consonanti e vocali. Finché la sillaba non è completa, appare sullo schermo, ma non è ancora un carattere confermato. Questo stato si chiama composizione.
È uno stato raro in inglese, ma quando si scrive in coreano si è quasi sempre nel mezzo di una composizione. Perciò anche un piccolo problema nella gestione della composizione diventa un grande disagio per chi usa il coreano.
Basta guardare le segnalazioni pubbliche. Typora presenta un problema su macOS per cui le parole coreane vengono inserite spezzate (#4251) e un problema per cui il cursore salta durante la composizione (#788). Obsidian presenta un problema per cui su Ubuntu alcuni caratteri coreani vengono omessi casualmente (#79528), un problema per cui su Wayland non è possibile inserire testo coreano (#84391) e un post sul forum secondo cui l'input viene ignorato in corrispondenza di un'interruzione di riga (#114224).
Le applicazioni erano diverse, ma il punto in cui si verificava il problema era simile. L'editor reinterpretava gli eventi di composizione sopra il motore del browser.
I caratteri non confermati non vengono inseriti nel documento
La shell Linux di mote non interpreta direttamente la composizione dell'hangul. Il compito di trasformare consonanti e vocali in sillabe viene affidato al metodo di input del sistema operativo.
I caratteri in fase di composizione vengono mostrati soltanto sullo schermo. Entrano nel documento solo dopo che la sillaba è stata confermata.
Questo solo principio ha eliminato diversi problemi.
Non viene creata una voce nella cronologia di annullamento a ogni passaggio della composizione. Il salvataggio automatico non scrive nel file sillabe non ancora complete. E le funzioni Markdown non tentano di applicare stili a caratteri che non sono ancora stati confermati.
Se si pensa al salvataggio automatico, la differenza diventa ancora più evidente. Durante la digitazione in coreano, una sillaba può essere ancora in fase di composizione anche in un breve momento di pausa. Se il carattere in composizione entrasse nel documento, potrebbe essere salvata una sillaba incompleta. E premendo una volta Annulla potrebbe essere cancellato un solo jamo.
Se si mantiene la composizione al di fuori del documento, non è necessario gestire separatamente queste eccezioni. Un carattere non confermato, infatti, non fa ancora parte del documento.
Lo schermo non si muove nemmeno durante la digitazione
All'inizio eliminavamo tutte le decorazioni Markdown dalla riga in cui era in corso una composizione. Sembrava una soluzione sicura, ma ha creato un nuovo problema.
Quando si inseriva testo coreano in un titolo, la riga si rimpiccioliva improvvisamente assumendo le dimensioni del corpo del testo. Tornava a essere un titolo solo al termine della digitazione. Poiché chi usa il coreano digita continuando a comporre caratteri, anche l'altezza della riga continuava a salire e scendere per tutto il tempo.
Ora il layout viene calcolato esattamente come se il carattere in composizione fosse già inserito nella riga. Quando si digita in un titolo, lo stile del titolo viene mantenuto anche sulla sillaba in composizione. Se si digita all'interno di un testo in grassetto, lo spessore non cambia. E i simboli Markdown nascosti non si sovrappongono al carattere in composizione.
Abbiamo eliminato anche la sottolineatura blu che appariva sotto il carattere in composizione. Sembrava infatti che la parte sotto la frase lampeggiasse per tutto il tempo in cui si scriveva in hangul. La composizione continua a funzionare allo stesso modo anche senza la sottolineatura.
Non è un semplice effetto visivo. Anche se tutti i caratteri vengono inseriti correttamente, se la riga continua a muoversi il flusso della scrittura viene interrotto. Per concentrarsi sulla frase, lo schermo deve restare tranquillo.

** appaiono in grigio e la parola '굵게' al loro interno mantiene il grassetto.Verifichiamo il comportamento reale invece di dire “supporta l'hangul”
Dire semplicemente “supporta l'hangul” non basta.
Non permette di sapere se sia sufficiente che i caratteri vengano inseriti o se anche lo schermo debba rimanere stabile durante la digitazione. È inoltre difficile verificare se, dopo essere passati a un'altra finestra e tornati indietro, l'ultima sillaba non scompaia o non venga inserita due volte.
Per questo mote ha trasformato una promessa vaga in una serie di verifiche concrete. A ogni rilascio inseriamo direttamente testo coreano usando un metodo di input reale e osservando lo schermo reale. Verifichiamo 12 condizioni in 9 situazioni e uno script registra i risultati in un file. Nell'esecuzione più recente sono state superate tutte e 12 le condizioni.
Neppure i casi di verifica sono stati inventati sulla base di supposizioni. Sono stati definiti prendendo come riferimento i problemi di input coreano segnalati pubblicamente in altri editor e le schermate di mote in cui potrebbero verificarsi problemi reali.
Controlliamo che il cursore non si sposti quando si digita all'interno di un testo enfatizzato. Verifichiamo anche che, dopo essere passati a un'altra finestra e tornati indietro, l'ultima sillaba venga confermata esattamente una volta. Controlliamo anche il caso in cui si inserisce testo coreano nella finestra di ricerca e poi si torna alla schermata di modifica. Ripetiamo lo stesso procedimento nelle celle delle tabelle, nella riga successiva di un elenco e nei titoli.
Le verifiche sono concrete. Per esempio, se si preme Invio durante la composizione di una sillaba, la sillaba completata deve rimanere sulla prima riga e solo il jamo appena inserito deve passare alla seconda. Se si preme una volta Backspace durante la composizione di ‘한’, invece di scomparire completamente il carattere deve diventare ‘하’.
Se vengono confusi i jamo con i caratteri completati, la verifica fallisce immediatamente.

Non diciamo che un ambiente è supportato se non lo abbiamo verificato
L'ambiente verificato direttamente a ogni rilascio è la combinazione X11 e ibus della shell Linux.
Il funzionamento di base della composizione con Wayland e fcitx5 viene verificato in 8 ambienti sperimentali separati. Tuttavia, l'ambito delle verifiche non è lo stesso. Anche le shell per macOS e Windows sono ancora in fase di sviluppo. Non dichiariamo di supportare il metodo di input di ciascun sistema operativo finché la verifica non è stata completata.
Esistono anche problemi che mote non può risolvere. Un esempio tipico è il comportamento per cui il metodo di input si avvia in modalità inglese ogni volta che viene aperto un nuovo campo di inserimento. Dopo aver chiuso la finestra di ricerca ed essere tornati alla schermata di modifica, potrebbe essere necessario premere di nuovo il tasto 한/영.
Questo problema si presenta comunemente nelle applicazioni GTK e può essere modificato nelle impostazioni del metodo di input. Non descriviamo come un nostro bug ciò che non lo è. Indichiamo invece dove si trova l'impostazione.
Un editor in cui è possibile inserire l'hangul e un editor in cui è piacevole scrivere in hangul sono due cose diverse.
Nel primo i caratteri vengono inseriti. Nel secondo il testo non si muove nemmeno mentre lo si digita.