GNU Emacs for Windows における最近の IMEパッチ問題

自分は GNU Emacs 使いなのですが、Windows版の Emacs を使用する場合、IMEパッチの問題がありました。

ざっくり言うと、FSFの正規のリリースバイナリだと日本語変換のIMEに切り替えた時、インラインで候補文字が表示されないという問題です。そのために有志の方々が IMEパッチを提供してくれておりまして（感謝）、それがあてられた 日本語Windows 向け Emacs を使うというのが上等手段となっています（なっていました）。

最近、Windows上の Emacs を更新しようかと思って、IMEパッチがあたった Emacs を探していたのですが、どうも最近は FSF がリリースする正規の Emacs バイナリが対応している「ダイナミックモジュール」という機能を使って、IMEパッチに相当する DLL をロードして、その対応をする方向で進んでいるみたいです。

その名称は

Emulator of GNU Emacs IME patch for Windows (tr-ime)

みたいで、GitHub上で公開されています。

https://github.com/trueroad/tr-emacs-ime-module

 詳細な説明も記載されてまして、その通りに対応することで、自分も無事、正規リリースの

GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)

 of 2022-09-14

で問題なく IME を使用できるようになりました。

それこそ、Mule/Meadow の時代から日本語Emacsを使っている身からすると、その日本語対応・多国語対応への進展は感慨深いです。

あと今回の導入において、Emacs-Lisp のパッケージ管理システムやリポジトリ：

MELPA (Milkypostman’s Emacs Lisp Package Archive)

も初めて知りました。これも便利そうですね。なお MELPA については以下の記事の内容が参考になりました（GNU標準リポジトリ GNU ELPA との違いなど）。

Emacsのpackage.elのリポジトリにMELPAを追加する

色々と進化していますね。

MSYS2/pacman のパッケージアップデートでのファイルダウンロード速度エラー

Windows上でのUnix環境ととして MSYS2/MinGW64 を常用しています。

今日、過負荷状態であるPC上で MSYS2/MinGW64 のパッケージアップデート:

pacman -Syu

を行っていた所、以下のメッセージが出て、アップデートが終了しました：

エラー: ファイル 'libxml2-2.10.4-1-x86_64.pkg.tar.zst.sig' を mirror.archlinux.tw から取得するのに失敗しました : 

Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds

このエラーに初めて遭遇したので、「ほう」という感じでした。

確かに超過負荷状態でしたが、「10秒間に10バイト未満しか取得できなかった」というのは「エラー」という程の状態なのですかね。。。

まだ「100秒間に100バイト未満しか取得できなかった」とか「300秒（5分）間に300バイト未満しか取得できなかった」という方が、なんとなくしっくりくる時間窓枠なのですが。。。

因みに実行していたのは「ディスクのクリーンアップ」での「Windows Updateのクリーンアップ」です。この処理はCPU利用率というよりはディスクアクセスが100%になるという状況でして、CPU利用率はさほど高くないですがIOアクセスが一杯で通信 and/or ディスクへのファイル保存ができない状態かと思います。

過去の経験上、Windows Update のクリーンアップが5分で終了するのは難しいかもしれませんが、pacman の方も、エラーで停止するよりは、「ダウンロードに時間かかっているけど継続する？」と確認メッセージを出して、一時停止してもらう方が状況的にもユーザインタラクション的にも合ってそうな気がするのですが。

ダウンロードに時間がかかるのが「エラー」と言われると、少し「うん？」と思いますし、「エラーの発生」に対してこちらのリアクションを思うと、もう少しフレンドリな扱いでも良さそうな気はします。

もちろん、そんなアップデートを行うのは一般にはシステム管理者（の位置づけの人）なので、

そういう過負荷状態でアップデートを敢行しようとは普通のシステム管理者はしないだろうから、その様な状況は想定外であり、エラー表示が適切

と言われるとそれまでなのですが笑、MSYS2/MinGW64であり、頻繁にパッケージアップデートがあることを考えると、もう少し軽い感じでも良さそうな気はします。

特に、一番最後の

警告: 複数のファイルの取得に失敗しました

エラー: 処理を完了できませんでした (予期しないエラー)

エラーが発生したため、パッケージは更新されませんでした。

という部分で、俺はそのぐらいの転送速度にはなるかもな、と予期はしていましたし笑

誰が予期してなかったのでしょうね。

TeXLive 2023のリリースと 64bit化

MSYS2 / MinGW64 の pacman アップデートで texlive の大量アップデートが発生したので「TeXLive 2023 がリリースされたんだろうなぁ」と思い、ネットで情報を検索してみたら、どうやらこのリリースから、

Windowsのtexアプリが 64bit化！

したみたいですね。

僕は LuaLaTeX 使いで、フォント使用時のメモリ利用量の問題があり、デフォルトが 64bit アプリである MSYS2/MinGW64 の 64bit 版 LuaLaTeX を使っていましたが、これからは TeXLive のデフォルトインストーラで提供されるものも 64bit 化されている様ですね。

今後、どっちを使おうかなぁ。。。

悩ましい所ですね。

LuaLaTeX には MSYS2 MinGW 64-bit がお勧め

自分は文書作成環境として LuaLaTeX を使うことが多いです。

理由は、

• LaTeXの様々なパッケージを使うことで効率的に文書を仕上げることが可能
• 文書の最終フォーマットはpdfで良いことが多く、LuaLaTeXにより直接pdfを出力可能であり、また pdf の機能を直接操作可能なパッケージも存在していること
• 日本語の入力やフォントをうまく扱うことが出来ること（utf-8入力という制約がありますが、逆に自分としては、新規に起こす文書は utf-8 なので問題ありません）

です。

ただ1つだけ難点がありました。

それは

Windows向けの texlive で普通にインストールすると、32bit実行形式の LuaLaTeX がインストールされ、デフォルト以外の日本語フォントを使用すると、メモリエラーでLuaLaTeXが落ちる

です。

「64-bit実行形式の LuaLaTeXなら、メモリエラーの問題は回避可能」というのは知っていまして、対策として「別途 64bit版のLuaLaTeXを差分インストールする」という手もあるのですが、インストールの手間は増やしたくないですし、なんか良い手はないかと思っていました。

因みに 64bit LuaLaTeX でデフォルト以外の日本語フォントを使用した場合のメモリ使用量の増減は、以下のようになっています：

縦軸の一目盛がだいたい1.5GBでして、LuaLaTeXのフォント処理時はトータルで二目盛ぐらいのメモリが必要となり、 3GB 程度、メモリを使用している模様です。64bitアプリということで、幾分かメモリ使用量が増加する所はあるかもしれませんが、32bit LuaLaTeX で扱うのは厳しいか、という印象ですね。

それとは別に、Windows上で C/C++ のコンパイル環境として

「MSYS2 MinGW 64-bit」

https://www.msys2.org/

を使っていたのですが、ふと、

MSYS2（64-bit）に texlive は入ってないのかな？

と思い、確認した所、ありました！

mingw-w64-x86_64-texlive-full

https://packages.msys2.org/groups/mingw-w64-x86_64-texlive-full

です。

MSYS2のパッケージインストーラ pacman を使い、

$ pacman -S mingw-w64-x86_64-texlive-full

とすれば普通に 64-bit版 LuaLaTeX が使えるようになりますし、メモリエラーは発生しません。

自分としては「Eclipse + texlipse」の環境で使うことが多いのですが、任意の日本語フォントを使用しても途中でメモリエラーで止まることがなくなり、大変重宝しています。