FunktionenPreiseDokumentationBlog
mote holen
← Blog
Design·18. Juli 2026·6 Min. Lesezeit

Wie man einen Editor entwickelt, in dem die koreanische Zeicheneingabe nicht auseinanderbricht

Wenn man längere Texte auf Koreanisch schreibt, kommt irgendwann der Moment, in dem die letzte Silbe verschwindet oder ein Wort auseinandergerissen wird. Das ist kein Tippfehler, sondern eine Frage dessen, wo der Editor die Zeichenkomposition verarbeitet.

m
mote
Eine auf Koreanisch geschriebene Überschrift im Live-Modus. Da sich der Cursor in dieser Zeile befindet, ist das # blass sichtbar, während die Zeichen ihre Größe und Stärke als Überschrift beibehalten.
Eine auf Koreanisch geschriebene Überschrift im Live-Modus. Da sich der Cursor in dieser Zeile befindet, ist das # blass sichtbar, während die Zeichen ihre Größe und Stärke als Überschrift beibehalten.

Beim Schreiben auf Koreanisch begegnet man bisweilen merkwürdigen Momenten. Am Zeilenende verschwindet ein Zeichen, und wenn man aus einem anderen Fenster zurückkehrt, wird die letzte Silbe doppelt eingegeben. Manchmal springt während der Eingabe auch der Cursor an eine völlig falsche Stelle.

Zunächst hält man das leicht für den eigenen Fehler. Doch meistens liegt es nicht an den Händen. Es passiert, weil der Editor die „Komposition“ koreanischer Zeichen nicht richtig verarbeitet.

Um ein einziges koreanisches Zeichen einzugeben, muss man mehrere Konsonanten und Vokale tippen. Bis die Silbe vollständig ist, wird sie zwar auf dem Bildschirm angezeigt, ist aber noch kein bestätigtes Zeichen. Diesen Zustand nennt man Komposition.

Im Englischen kommt dieser Zustand selten vor, beim Schreiben auf Koreanisch befindet man sich jedoch fast ständig mitten in einer Komposition. Deshalb wird selbst ein kleines Problem bei deren Verarbeitung für koreanische Nutzer zu einer erheblichen Beeinträchtigung.

Das zeigen schon die öffentlich gemeldeten Probleme. Bei Typora gibt es ein Problem, bei dem koreanische Wörter unter macOS getrennt eingegeben werden (#4251), sowie eines, bei dem der Cursor während der Komposition springt (#788). Bei Obsidian gibt es ein Problem, bei dem koreanische Zeichen unter Ubuntu zufällig fehlen (#79528), eines, bei dem die koreanische Eingabe unter Wayland nicht funktioniert (#84391), und einen Forumsbeitrag darüber, dass Eingaben an Zeilenumbrüchen ignoriert werden (#114224).

Die Apps waren unterschiedlich, doch die problematische Stelle war ähnlich. Der Editor interpretierte die Kompositionsereignisse über einer Browser-Engine neu.

Noch nicht bestätigte Zeichen werden nicht in das Dokument eingefügt

Die Linux-Shell von mote interpretiert die koreanische Zeichenkomposition nicht selbst. Die Aufgabe, aus Konsonanten und Vokalen Silben zu bilden, überlässt sie der Eingabemethode des Betriebssystems.

Zeichen, die sich noch in der Komposition befinden, werden nur auf dem Bildschirm angezeigt. Erst nachdem eine Silbe bestätigt wurde, gelangt sie in das Dokument.

Allein durch diesen einen Grundsatz verschwanden mehrere Probleme.

Es wird nicht bei jedem Kompositionsschritt ein Eintrag im Rückgängig-Verlauf erzeugt. Die automatische Speicherung schreibt keine unvollständigen Silben in die Datei. Und die Markdown-Funktionen versuchen auch nicht, noch nicht bestätigte Zeichen zu formatieren.

Bei der automatischen Speicherung wird der Unterschied noch deutlicher. Während der koreanischen Eingabe kann sich eine Silbe selbst in einem kurzen Moment des Innehaltens noch in der Komposition befinden. Würde ein Zeichen während der Komposition in das Dokument eingefügt, könnte eine halbfertige Silbe gespeichert werden. Und bei einem einzigen Druck auf „Rückgängig“ könnte nur ein einzelnes Jamo gelöscht werden.

Wenn die Komposition außerhalb des Dokuments bleibt, müssen solche Ausnahmefälle nicht gesondert behandelt werden. Denn ein noch nicht bestätigtes Zeichen ist noch kein Teil des Dokuments.

Auch während der Eingabe bleibt die Anzeige ruhig

Anfangs entfernten wir in der Zeile, in der gerade eine Komposition stattfand, sämtliche Markdown-Formatierungen. Das wirkte sicher, führte aber zu einem neuen Problem.

Wenn man Koreanisch in eine Überschrift eingab, schrumpfte die Zeile plötzlich auf die Größe des Fließtexts. Erst nach Abschluss der Eingabe wurde sie wieder zur Überschrift. Da koreanische Nutzer während der Eingabe fortwährend Zeichen komponieren, bewegte sich auch die Zeilenhöhe beim Schreiben ständig auf und ab.

Jetzt wird das gerade komponierte Zeichen so berechnet, wie es innerhalb der Zeile erscheint. Bei der Eingabe einer Überschrift bleibt der Überschriftenstil auch für die Silbe erhalten, die gerade komponiert wird. Auch bei der Eingabe innerhalb von Fettschrift ändert sich die Schriftstärke nicht. Verborgene Markdown-Zeichen überdecken das gerade komponierte Zeichen ebenfalls nicht.

Auch die blaue Unterstreichung, die unter dem gerade komponierten Zeichen erschien, haben wir entfernt. Denn dadurch wirkte es, als würde während des gesamten Schreibens auf Koreanisch unter dem Satz etwas blinken. Die Kompositionsfunktion arbeitet auch ohne diese Unterstreichung unverändert weiter.

Das ist nicht bloß ein visueller Effekt. Selbst wenn alle Zeichen korrekt eingegeben werden, unterbricht eine ständig wackelnde Zeile den Schreibfluss. Nur wenn die Anzeige ruhig bleibt, kann man sich auf den Satz konzentrieren.

Eine Zeile mit koreanischer Eingabe innerhalb von Fettschrift — Da sich der Cursor in dieser Zeile befindet, sind die **-Marker grau sichtbar, während das darin stehende „굵게“ seine Fettschrift beibehält.
Eine Zeile mit koreanischer Eingabe innerhalb von Fettschrift — Da sich der Cursor in dieser Zeile befindet, sind die **-Marker grau sichtbar, während das darin stehende „굵게“ seine Fettschrift beibehält.

Statt „Unterstützung für Koreanisch“ prüfen wir das tatsächliche Verhalten

Die bloße Aussage „Koreanisch wird unterstützt“ reicht nicht aus.

Sie verrät nicht, ob es genügt, dass die Zeichen eingegeben werden können, oder ob auch die Anzeige während der Eingabe stabil bleiben muss. Ebenso lässt sich nur schwer feststellen, ob die letzte Silbe nach einem Wechsel zu einem anderen Fenster weder verschwindet noch doppelt eingefügt wird.

Deshalb hat mote ein vages Versprechen in konkrete Prüfpunkte verwandelt. Bei jeder Veröffentlichung geben wir Koreanisch direkt mit einer echten Eingabemethode auf einer echten Benutzeroberfläche ein. In neun Situationen prüfen wir zwölf Bedingungen, und ein Skript hält die Ergebnisse in einer Datei fest. Beim jüngsten Durchlauf wurden alle zwölf Bedingungen erfüllt.

Auch die Prüfpunkte haben wir uns nicht einfach ausgedacht. Wir haben sie auf Grundlage öffentlich gemeldeter Probleme bei der koreanischen Eingabe in anderen Editoren und anhand von Ansichten festgelegt, in denen bei mote tatsächlich Probleme auftreten könnten.

Wir prüfen, ob sich der Cursor bei der Eingabe innerhalb einer Hervorhebung bewegt. Wir sehen auch nach, ob die letzte Silbe bei der Rückkehr aus einem anderen Fenster genau einmal bestätigt wird. Außerdem testen wir die Situation, in der man im Suchfenster Koreanisch eingibt und anschließend zur Bearbeitungsansicht zurückkehrt. Den gleichen Ablauf wiederholen wir in Tabellenzellen, in der Zeile nach einer Liste und in Überschriften.

Die Prüfungen sind konkret. Wenn man beispielsweise während der Komposition einer Silbe Enter drückt, muss die fertige Silbe in der ersten Zeile bleiben, während nur das neu eingegebene Jamo in die zweite Zeile gelangt. Drückt man einmal die Rücktaste, während man „한“ komponiert, darf nicht das gesamte Zeichen verschwinden, sondern es muss zu „하“ werden.

Werden Jamo und fertige Zeichen verwechselt, schlägt die Prüfung sofort fehl.

Eine Tabelle mit den Punkten, die bei jeder Veröffentlichung bestanden werden müssen — Links steht, was eingegeben wird, in der Mitte, welches Ergebnis für ein Bestehen erforderlich ist, und rechts die Nummer des öffentlichen Issues, aus dem der jeweilige Punkt hervorging.
Eine Tabelle mit den Punkten, die bei jeder Veröffentlichung bestanden werden müssen — Links steht, was eingegeben wird, in der Mitte, welches Ergebnis für ein Bestehen erforderlich ist, und rechts die Nummer des öffentlichen Issues, aus dem der jeweilige Punkt hervorging.

Für nicht geprüfte Umgebungen versprechen wir keine Unterstützung

Die Umgebung, die bei jeder Veröffentlichung direkt geprüft wird, ist die Kombination aus X11 und ibus in der Linux-Shell.

Für Wayland und fcitx5 prüfen wir das grundlegende Kompositionsverhalten in acht separaten Testumgebungen. Der Umfang der Prüfungen ist jedoch nicht derselbe. Auch die Shells für macOS und Windows befinden sich noch in der Entwicklung. Solange die Eingabemethode des jeweiligen Betriebssystems nicht vollständig geprüft wurde, behaupten wir nicht, sie zu unterstützen.

Es gibt auch Probleme, die mote nicht beheben kann. Ein typisches Beispiel ist das Verhalten einer Eingabemethode, die jedes neu geöffnete Eingabefeld im englischen Modus startet. Nachdem man das Suchfenster geschlossen hat und zur Bearbeitungsansicht zurückgekehrt ist, muss man deshalb möglicherweise erneut die Taste zum Wechseln zwischen Koreanisch und Englisch drücken.

Dieses Problem tritt allgemein in GTK-Apps auf und lässt sich in den Einstellungen der Eingabemethode ändern. Wir stellen etwas, das nicht unser Fehler ist, nicht als unseren Fehler dar. Stattdessen dokumentieren wir, wo sich die entsprechende Einstellung befindet.

Ein Editor, in dem Koreanisch eingegeben werden kann, ist nicht dasselbe wie ein Editor, in dem man gut auf Koreanisch schreiben kann.

Beim ersten werden die Zeichen eingegeben. Beim zweiten bleibt der Text auch während des Tippens ruhig.

← Älter"0.9.0-beta.1: Was unsere erste öffentliche Beta enthält"Neuer →Warum wir jedes Mal in acht verschiedenen Linux-Umgebungen testen
Bleiben Sie per RSS auf dem Laufenden.
Nur das Schreiben bleibt.
Deutsch
© 2026 mote