ハングルの文字合成が崩れないエディターを作る方法

韓国語で文章を書いていると、おかしな瞬間に出会うことがあります。行末で文字が消え、別のウィンドウから戻ってくると最後の音節が二重に入力されます。入力中にカーソルが見当違いの場所へ動くこともあります。

最初は自分のミスだと思いがちです。しかし、ほとんどの場合は手の問題ではありません。エディターがハングルの「文字の組み立て」を正しく扱えないために起こります。

ハングルを一文字入力するには、子音と母音のキーを複数回押す必要があります。音節が完成するまでは画面に見えていても、まだ確定された文字ではありません。この状態を文字の組み立てと呼びます。

英語では珍しい状態ですが、韓国語を書くときはほとんど常に組み立て中です。そのため、組み立て処理に小さな問題があるだけでも、韓国語ユーザーには大きな不便となります。

公開されているイシューを見るだけでも分かります。Typoraには、macOSでハングルの単語が分かれて入力されるイシュー（#4251）と、組み立て中にキャレットが飛ぶイシュー（#788）があります。Obsidianには、Ubuntuでハングルがランダムに欠落するイシュー（#79528）、Waylandでハングルを入力できないイシュー（#84391）、改行位置で入力が無視されるというフォーラム投稿（#114224）があります。

アプリは違っても、問題が起きる場所は似ていました。エディターがブラウザーエンジン上で組み立てイベントを再解釈していました。

確定されていない文字は文書に入れません

moteのLinuxシェルは、ハングルの組み立てを直接解釈しません。子音と母音から音節を作る処理は、OSの入力メソッドに任せます。

組み立て中の文字は画面にだけ表示されます。音節が確定されてから初めて文書に入ります。

この一つの原則によって、さまざまな問題がなくなりました。

文字を組み立てるたびに取り消し履歴が作られることはありません。自動保存が未完成の音節をファイルに書き込むこともありません。Markdown機能が、まだ確定されていない文字を装飾しようとすることもありません。

自動保存について考えると、違いはさらに明確です。韓国語を入力している間は、少し手を止めた瞬間にも音節が組み立て中である可能性があります。組み立て中の文字が文書に入るなら、中途半端な音節が保存される可能性があります。取り消しを一度押しただけなのに、字母が一つだけ消えることもあります。

組み立て中の文字を文書の外に置けば、このような例外を個別に処理する必要はありません。確定されていない文字は、まだ文書ではないからです。

入力中も画面を揺らしません

最初は、組み立て中の行からMarkdownの装飾をすべて取り除いていました。安全に見えましたが、新たな問題が生じました。

見出しにハングルを入力すると、その行が突然本文と同じサイズまで小さくなりました。入力を終えて初めて見出しに戻りました。韓国語ユーザーは文字を組み立て続けながら入力するため、書いている間ずっと行の高さも上下しました。

今は、組み立て中の文字が行の中に入った状態のまま計算します。見出しを入力すれば、組み立て中の音節にも見出しのスタイルが維持されます。太字の中で入力しても、太さは変わりません。非表示のMarkdown記号が組み立て中の文字を覆うこともありません。

組み立て中の文字の下に表示されていた青い下線もなくしました。ハングルを書いている間ずっと、文章の下が点滅しているように見えたためです。下線がなくても、文字の組み立て機能はそのまま動作します。

これは単なる画面効果ではありません。文字がすべて入力されたとしても、行が揺れ続ければ書く流れが途切れます。画面が静かであってこそ、文章に集中できます。

「ハングル対応」ではなく実際の動作を確認します

「ハングルに対応しています」という言葉だけでは不十分です。

文字さえ入力できればよいのか、入力中も画面が安定しているべきなのかが分かりません。別のウィンドウから戻ってきても、最後の音節が消えたり二重に入力されたりしないかどうかも確認しにくいです。

そこでmoteは、漠然とした約束を具体的な検査項目に変えました。リリースのたびに、実際の入力メソッドと実際の画面でハングルを直接入力します。9つの状況で12の条件を確認し、結果はスクリプトがファイルに残します。直近の実行では、12の条件をすべて通過しました。

検査項目も想像で作ったものではありません。他のエディターで公開されているハングル入力の問題と、moteで実際に問題が起こり得る画面をもとに決めました。

強調の中で入力するときにカーソルが動かないか確認します。別のウィンドウから戻ってきたとき、最後の音節が正確に一度だけ確定されるかも見ます。検索ウィンドウでハングルを入力したあと、編集画面に戻る状況も検査します。表のセル、リストの次の行、見出しでも同じ過程を繰り返します。

検査は具体的です。たとえば、音節を組み立てている途中でEnterを押した場合、完成した音節は1行目に残り、新しく入力した字母だけが2行目へ移らなければなりません。「한」を組み立てている途中でBackspaceを一度押した場合、文字全体が消えるのではなく「하」にならなければなりません。

字母と完成した文字を混同すれば、すぐに失敗となります。

確認していない環境を対応済みとは言いません

リリースごとに直接確認する環境は、LinuxシェルのX11とibusの組み合わせです。

Waylandとfcitx5については、別途用意した8種類の実験環境で基本的な組み立て動作を確認します。ただし、検査範囲は同じではありません。macOSとWindowsのシェルもまだ開発中です。各OSの入力方式は、検証を終えるまで対応しているとは言いません。

moteでは直せない問題もあります。入力メソッドが新しい入力ウィンドウを開くたびに英語モードで開始する動作が代表的です。検索ウィンドウを閉じて編集画面へ戻ったとき、韓国語／英語キーをもう一度押す必要がある場合があります。

この問題はGTKアプリで共通して発生し、入力メソッドの設定で変更できます。私たちのバグではないものを、私たちのバグであるかのようには書きません。その代わり、設定がどこにあるのかを記しておきます。

ハングルを入力できるエディターと、ハングルで書きやすいエディターは違います。

前者は文字が入力されます。後者は入力している間も文章が揺れません。