現在の Emacs でかんなを使う

Emacs 25

canna.el に代わり、かん なの日本語入力を input method として行うための canna-im.el の 配布を始めました。よければお試しください。

Canna for GNU Emacs 25」への僅かな修正点を公開します。

emacs 25.2 のソースを入手したら、 「Canna for GNU Emacs 25」で公開されている emacs25.2canna-20170507.diff.gz を適用します。そうしたら、 configure を実行する前に
Download: additional-patch-25.2.bz2(8910 bytes) [2017, 4/30]
のパッチを当ててください。

その後で普通に configure, make で基本的にいいのですが、その前にちょっ とコメントを加えておきます。

私の独自パッチの効能は以下の通りです。

  1. [2017, 5/11] coding.c に対 する1発目の修正ですが、これは {de,en}code-coding-string の doc string でOptional third arg NOCOPY non-nil means it is OK to return STRING itself if the {de,en}coding operation is trivial.となっていることから、こうなっ ていないとおかしいはず、ということで入れてあります(かんなとは無関係な、emacs 本体への修正)。 以前 mule-ja で報告した時は結局何の反応もなかったので慎重になっ ていたのですが、昔の(内部 unicode 化以前の)coding.c の処理と見比べてたぶん正しいはず、と思えたので追加しました。emacs 21.4, 22.3 での code_convert_string1 での該当部は
    if (NILP (coding_system)) return (NILP (nocopy) ? Fcopy_sequence (string) : string);
    となっていて、これは明らかに nocopy が真でない時に string のコピーを返すようになっています。また、 {de,en}code_coding_string 中にも
    return (nocopy ? str : Fcopy_sequence (str));
    といった行が見受けられ、こちらも今回の修正と合致したロジックです (また、その周りを眺めてみると、やはりどうやら「{de,en}coding operation is trivial」に該当する場合の特殊処理のように見えます)。 そもそも、emacs 23 以降の coding.c では、nocopy 引数は ほとんど登場する場面がなく、実質的にこの 1 ヶ所だけです。つまり指定 された coding system が nil だった場合のみ nocopy 引数は意味を持ち、それ以外の場合はすべて無視されます(emacs 22 まではまだそれなりに意味のある場面があったようですが…)。つまり、 この nocopy 引数はほとんど後方互換性のためだけに残してあるようなも のであって、プログラム中で意味のある使い方をしている部分は事実上残っ ていないのでしょう。このため、nocopy 引数に対するロジックが逆になっ ていても、これまでまったく問題が生じることなく何年もの間見過ごされ てきたのだと思います。どの道、この nocopy 引数の意味は allow nocopy であって inhibit copy ではなく、利用する側は copy されていてもされ ていなくても変わらず動くように書く必要があったことからしても、結局 この修正はあってもなくても事実上影響がないものなのでしょう。 なお、canna.c 中では毎回律儀に nocopy 引数を真にして code_convert_string を呼んでいますが、ここで canna-coding-systemnil になることはあり えないはずなので、そこの真偽は結果に何ら影響していなかった、という わけです。
  2. [2017, 4/30] mule-ja での以下の 2 点の修正は、emacs 25 にはまだ取り 入れられていないので先取りして入れてあります(かんなとは無関係な、emacs 本体への修正)。
  3. [2016, 10/14] fill で挿入される改行に、付けるべきでは ない(と思われる)text property を付けないようにした(かんなとは無 関係・emacs 本体の修正)。
  4. [2015, 6/25]
  5. ひらがな←→カタカナ変換のテーブルに、踊り字を追 加(これもかんなとは無関係な、emacs 本体の修正)。 [2016, 10/14] この修正は emacs 本体に取り入れられていますが、25 に は取り入れられていないので引き続き入れておきます。
  6. [2015, 6/3] canna-finalize でかんなを終了する際の返り 値の処理に不備があり、warning があっても一切無視されていたのを修正 しました。返り値も、ドキュメント通りのものが正しく返るように修正し てあります。
  7. [2015, 5/16] 補助漢字や、JIS 第四水準の文字(EUC コードで3バイトで 表される文字)の扱いに不備があったので修正しました。具体的には、次 の問題がありました。
    1. canna-underline, canna-use-color が共に nil(デフォルトはそう)で、変換候補(未確定文字列)の着目文節に3バ イト文字が現れるとき、カーソルの位置がずれる。
    2. ミニバッファでの表示に3バイト文字が現れるとき(候補一覧に含ま れる場合や、単語登録などの場面)、カーソルの位置がずれる。
    この問題はかなり前(おそらく、Mule 1 か 2 の頃)から生じていたはず なので、これまで放置されていたのは、おそらくかんなで3バイト文字を 利用するような機会がこれまでほとんど誰にもなかったからなのでしょう。
  8. [2013, 3/29] C-SPC などで mark を打ったとき、日本語モードなら再変換領域の設定も行っていました (canna-use-space-key-as-henkan-regionnil でないとき)が、C-u C-SPC などで pop-buffer 系のコマンドが実行されていた場合はその動作は適切ではない と思われるため、その場合は再変換領域を設定しないようにしました。
  9. [2012, 5/7] delete キーがうまく canna に処理されず、動作がおかしく なることがあったのを修正。(私の配慮不足が原因で、function key map に よって deleteC-? に置換されると思い込ん でいたのが誤りでした。実際には、例えば (global-set-key [delete] 'delete-backward-char) のようにして、その時点で有効な他の keymap に delete が 直接定義されていた場合は、 function key map によるそのキーの置換は 無効になってしまうため、delete がかんなで処理されなくなっ てしまっていました。なお、これは実は delete に限った話 ではなく、tabreturn などの、「文字端末上 だったら ascii の control code を発するキー」はほぼすべて共通で、 これらが active keymap 上に直接定義されていた場合は、かんなでの処 理をすり抜けてしまっていました) [2012, 6/19] …と書きましたが、現状の canna.el をよく 見てみると、canna-functional-insert-command 内の例外 処理によって、実はその問題はカバーされていたようにも見えます。この 件は私の早とちりだったかもしれません。
  10. [2012, 5/7] C-SPC でかんなのエラーが発生する場合、After 0 kbd macro iterations: canna:functional-insert-command2: Keyboard macro terminated by a command ringing the bell という warning が出て しまっていたのを修正。(これは、C-SPC を押したときに、 keyboard macro として C-@ を実行するという動作だったた め。なお、backspace も keyboard macro で C-h を実行する動作だったので、潜在的には同じ問題がありましたが、かんな を普通に使っている場合は、C-h でかんなのエラーになる場 合というのはほとんど存在しないので、事実上 C-SPC に限ら れる問題でした)※ ひょっとしたら、この warning は昔の emacs では 出ていなかったのかも…。
  11. C-@C-SPC で出るメッセージを、固定メッセー ジから(本来の set-mark-command が出す)動的メッセー ジに修正。
  12. characters.el, kinsoku.el への修正も追加 しましたが、これらはできあがった emacs の動作には影響を与えません (これもかんなとは無関係な、emacs 本体の修正)。 この修正も emacs 本体に取り入れられていますが、emacs 25 には含まれ ていないので引き続き入れておきます。
  13. ファンクションキー等の特殊キーに、かんなの機能を割り当てたとき、 X window 上なら確実に有効となる。また、ターミナル上でも制限つきなが ら利用可能となる。利用できる特殊キーは以下の通り。 ただし、重大な制限があります。これらの特殊キーは (だけじゃなくて、.cannaで設定しているその他の普通のキー も)、単に日本語入力モードをオンにするだけでは働かなくって、フェ ンスモードに入ったときだけしか有効になりません。フェンスモード に入る前に有効化するのは難しいですし、Emacs のもともとのキー操作とぶ つかってしまって困ると思います。がんばればその辺りも何とかなるかもしれませ んが、それほど需要が高いとも思えませんし、そのために努力を傾けるよりも 別のことに注力した方がよいでしょう。
  14. 文字端末(tty)上で特殊キーを使うには、準備として、 .emacs のかんなの初期化を行った後の所で、
    (when (not window-system)
          (define-key canna-mode-map "\e" nil)
          (define-key canna-minibuffer-mode-map "\e" nil))
    のようにして、フェンスモードでのエスケープキーへのキーバインドを解除 しておく必要があります(そうすることによって、 function-key-map が有効となり、ファンクションキーの発生 するエスケープシークエンスが特殊キーとして再解釈されるようになる)。 このため、文字端末上では特殊キーとエスケープキーの両方にかんなの 機能を割り当てることはできません。二者択一となります(なので、例 えば ATOK の動作を kterm 上で忠実に再現することはできませ ん)。※ エスケープキーの処理をうんと特殊にすれば、両立も可能となるかもし れませんが…。[2012, 5/18] また、Emacs 23 からは、1つの Emacs が文字端末上でも window system 上でも同時に動くこ とも可能になったので、こういうwindow-system の値にもとづく 使い分けは厳密にはできなくなっている…という新たな問題があります。

ファンクションキーが有効になった結果の副作用として、かんなの日本語入 力処理が止まり、何を入力してもウンともスンとも言わなくなってしまうことが あります。解決法は後述しますが、具体的な症状は「.cannaromaji-yuusent になっている場合、ローマ字入 力の段階で "n" が未確定の状態のとき、『無変換』キー をうっかり押してしまうと、"n" が『ん』に変化した状 態で表示が固まってしまい、以後その emacs セッション内ではかんなが無反応 となる(canna lib に処理を渡すような、通常キーの入力は全滅)」というもの です。

この状態になってしまった場合は、M-x canna-reset を実行すれ ば復旧できます(X window 下では、大抵 Alt キーが Meta キーとして使えるの で、Meta-x は emacs に渡すことができ入力可能。文字端末(tty) 環境下では、ESC が canna に渡ってしまう場合は強制終了するしか 手がないかもしれません…)。

これはかんな側のバグらしく、開発元に連絡した所、 修正パッチを作って頂けました(ただ、これはまだ暫定的な修正だったらし く、その後 CVS に投入された変更はもっと多岐に渡っているようです。きちん と直したい方は CVS から開発版を導入してください)。

なお、数年前から私は emcws の canna.elまったく使っ ておりません。Emacs Lisp 側のインターフェースは、canna.el を改造してかんな/Emacs を input method 化したものを使っていま す(未公開 [2012, 5/18] 試験的に公開を始めてみました)。 ですので、上記の canna.el には何か重大なバグがあるかもしれません。ご了承ください。

かんなを用いた日本語入力

日本語入力モードの切り替えキーについて

かんなの標準では、日本語入力モードのオン・オフは C-o に 割り当てられています。が、もともと Emacs では C-o は空行を 発生させるキー操作で私はよく使いますし、か んなの前は最初は Tamago を使っていたということもあって、Tamago と同 じ C-\ を日本語入力モードのオン・オフに割り当てています。

同じことを感じる人も多いらしく、web page にはよくその方法の説明があ るのですが、ほとんどは

.emacs
(global-set-key "\C-\\" 'canna-toggle-japanese-mode)
と書け
というアドバイスになっているようです(例えば FreeBSD Q&A 578 など)。

しかし、これでは C-o が相変わらず日本語入力の切り替えに乗っ 取られたままで、それを元に戻す設定を付け加えなくてはなりません。また、 日本語入力の切り替えキーが他のかんなクライアントと違ってしまうことにな り、「かんなのキー操作の統一性」(下記参照)からすると望ましいとは言え ません。ここは、かんな/Emacs の info(注)mule 2.3 には最初からついているはずです。 Emacs 20 以降は、emcws と同じ所から mule-2.3-19.34-info.tar.gz が取れ るでしょう)に従って、かんな側の設定として

.canna
(global-unbind-key-function 'japanese-mode)
(global-set-key "\C-\" 'japanese-mode)
と書いておく
のがよいでしょう。こうすれば、かんな/Emacs を起動して cannaserver との 接続が行われたときに、自動的に C-\ の方に日本語入力モードの オン・オフが設定されます(なお、.emacs(Emacs Lisp)では C-\ のことを "\C-\\" で表しますが、 .canna(canlisp)では "\C-\" で表します。 これが明記してある文書は、私には Canlispマニュア ル以外には見つけられませんでした)。

※ かんな/Emacs の info

Mule 2.3 付属のものや、mule-2.3-19.34-info.tar.gz に含まれているも のは(なぜか)ちょっとバージョンが古いようです。 mule-2.3-19.34-man.tar.gz に含まれている texinfo ファイルから info ファイルを生成し直した方がよいでしょう。

生成するには、texinfo ファイルを emacs で読み込んで、M-x texinfo-format-buffer…だったかな?

[2010, 1/7] undo 時の処理について

上述の info 中では、「マルやテンなど、確定文字列が1文字だけのときは アンドゥ(再変換)の対象にせず、その直前に確定した(もっと長い)文字列を アンドゥ(再変換)の対象に保ったままにする」ために、 canna-save-undo-text-predicate を利用したカスタマイズのやり方 が紹介されています。が、そこの記述は、Nemacs 時代の、日本語が内部コード で 2 バイトで表現されている時代のもので、「確定文字列の長さ(バイト数) が 2 よりも大きいか否か」で判断を行っていたため、現状では意図する動作と 若干違ってきてしまっています。

emacs 20 の途中から、length 関数は「バイト数」ではなく「文字数」を返 すようになった(日本語などの多バイト文字でも、1文字は1文字とカウントす る)ので、現状ではここは


(setq canna-save-undo-text-predicate 
   (lambda (s) 
      (> (length (car s)) 1) ))

のように、「確定文字列の長さ(文字数)が 1 よりも大きいか否か」で判断するのが正しいカスタマイズとなります(2 の ままだと、マルやテンだけでなく、ちょうど2文字の文字列を確定させたと きも、アンドゥ(再変換)の対象にならなくなる)。

なお、現状では lambda の先頭に「'」を付ける必要はなくなっ ているので、それも取り除いてあります。

私はプログラミングについてはずぶの素人ですから、まずい点、 アホな点が一杯あるかもしれません。このページの内容は完全に無保 証です。くれぐれも、鵜呑みになさらないようお気をつけください。


ずーっと以前に私が fj.editor.muleに 投稿した、考えなしなパッチがそのまま Mule に取り込まれてしまったせ いで、以前の emcws には

という重大なバグがありました(当時は、「Mule のよう な重要で広く使われているソフトの開発者さんたちは、とびきりの腕利きの人た ちのはずだから、私のいい加減なパッチをそのまま取り込んだりはしないで、ま ずい点があれば魔法のように発見して正しく修正してくれるだろう」と思ってい て、あんまり自分のバグには気を払わなかったのです…)。

というわけで、 中島さんのお怒りの件の一部は実は私に責任があります(すみません…)。

のちになってこれらのバグが明らかになったとき、 その部分の変更を 取り消すパッチも投稿したのですが、そちらの方はその後の Mule・Emacs の開発には取り込まれずに残ってしまいました。

[2009, 12/29] emcws-22.2-20071105 以降は、このページで公開していた patch を取 り込んでいただいたので、現在はその問題はなくなっています。


コンピュータ関連のページ目次へ
トップページへ
井汲 景太 <ikumikeita@jcom.home.ne.jp.NOSPAM.>(迷惑メールお断り)
最終更新日: 2017年5月13日