昔の最近の出来事(2024.06)

2024/06/30

AM中に起床。

雨が降る前にちょろり買い物にお出かけ。

掃除したり洗濯したり。

Unicode15.1の「⛓️‍💥」絵文字の表示がEmacsでイケてない件。 先日、フォント設定を変えればイケるのは判ったのですが やはり副作用があります。 設定を変える前は「🌶(VS16無し)」と「🌶️(VS16有り)」とで、 前者は Segoe UI Symbol、後者は Segoe UI Emoji で表示が切り替わっていたのですが、 Segoe UI Emojiを前面に持ってきた為、VS16の有無に関係無く Segoe UI Emojiで表示されるようになりました😓。 唐辛子と同じく 変更前のフォント設定に戻して、「⛓(VS16無し)」と「⛓️(VS16有り)」の 両方を表示してみたところ、どちらも Segoe UI Symbol で表示されました。 むむ？ここに秘密がある予感。
「🌶(VS16無し)」と「🌶️(VS16有り)」の表示の切り替えはどうやってるんだ？ それと同じ仕組みで「⛓(VS16無し)」と「⛓️(VS16有り)」の表示が切り替えられれば 「⛓️‍💥」の表示もうまくいくのでは？と思ったり。 admin/unidata/emoji-data.txt や admin/unidata/emoji-sequences.txt の「chains」の 近くにある絵文字を見てみたのですが VS16の有無で表示が切り替わります。 なぜ「⛓」が切り替わらないのか謎🤔

ひとまず「⛓(VS16無し)」と「⛓️(VS16有り)」の切り替えの件は置いといて、 以下のような感じで Windows11では Unicode 15.1の絵文字も表示できるようになりました。



Windows10だと Unicode 12.0 の合字までしか表示できないのか と改めて思ったりも。 Unicode 13.0がリリースされたのは2020年3月10日らしいのですが、Windows11が発表されたのは 2021年6月24日だったのを鑑みますに、Unicode 13.0がリリースされた時期には Fluent絵文字(いまだに Windows11のSegoe UI Emojiの事を何て呼ぶのか判らない😓)に移行中だったのかも。 そうだとすれば Windows10の Segoe UI Emoji のアップデートをする気は無くなっていたんじゃないかとは思ったりも。 ただの憶測ですが。

鬼滅の刃の柱稽古編 最終回。ほのぼの要素を挟めるのはここまでか。 無限城編は劇場版で三部作になるみたい。どんな映像クオリティになるのだろう。

AM中に起床。

Emacs30 で plinkを使った TRAMP接続ができなくなった件。 先日のlisp/net/tramp-sh.el内の 関数tramp-ssh-controlmaster-options から周りを眺めてみたところ、 tramp-use-connection-share というカスタム変数があるのが判りました。 このカスタム変数の初期値は 「(defcustom tramp-use-connection-share (not (eq system-type 'windows-nt)) ...)」 となっていて、windows-ntの場合は nilになるようです。 で、Cygwinビルドなので tになっています。 このカスタム変数を nilにしてみたところplinkでの接続はイケるようになるようです。 このカスタム変数の値に応じて plink実行時のオプションに -noshare か -share のどちらかの オプションを追加するようになったようです(29.4には無い仕組み)。 そもそも 使っているメソッドとかではなくて windows-ntか否かで切り替わるってのが そうなのか？とは思ったりも。さておき、やっぱり 1回はイケた説明が付かないです。 一旦忘れるか...😓

そういえば、Emacs29になった頃から、image-diredでファイル数が多いと(?) サムネイルが 表示され始めるまでに時間がかかるようになっています(以前のメモ)。 サムネイル画像は ディレクトリ ~/.emacs.d/image-dired の中に保存されるのですが、 「watch -n 1 'ls -ltr --full-time | tail -20'」でファイルの生成状況を観察していると、 いくつかファイルを作った後は、なぜか生成されては消えているようです。何かしらの処理が一通り終わると 画面への表示が行なわれ始め、生成されたファイルも消える事無く保存され始めるという感じに 動いています。直感的には何かしら無駄な検査を行なっているんじゃないか？という疑惑。
調べてみたところ、ファイルを消す要素は無いように思ったり。パッチの影響を確認してみたところ、 一点、run-at-timeを使用した非同期実行だったのを同期実行に変えてたところがあり、なにげにそれを 元の非同期実行に戻してみたところ、すぐに画面に表示されるようになりました。 実際に起こっているファイルが生成されては消える動きと、非同期実行でイケるようになった事 との因果関係がまだ結びついていないのですが、ともかく自分のせいでした。修行が足りません🥺。 この対応は 28.xではサムネイル表示中に別の操作を行なうと ハング状態に陥っていたので 入れていました。29.xは 28.xを移植したので同じように入れた感じでした。 28.xでの image-diredのハングの原因は 色々有り過ぎて今回の件も 対処になっていたのがいつの間にか悪さをするようになっていたという感じだったかも。 一応すぐに画面更新が行なわれるようになったものの、動きは大分もっさりしているので 乱暴に扱っても大丈夫か？は少しテストしてみないと判らない感じかも。

libjxlの v0.10.3がリリースされたらしい。 デコードに関するバグが修正されたようですが、それだけの為にリリースしたのかどうかは判りません。

そういえば、TRAMPでは「/plink:user1@host1|podman:container_id:/path_to/foo.jpg」のように host1上のpodmanコンテナ内のファイルをアクセスする事ができますが、image-diredでサムネイルを 生成するコマンドに渡せるか？と思って調べてみたところ、コマンドの引数には 「/podman:container_id:/path_to/foo.jpg」のように、途中の経路に関するパスは含まれない ようだったり。これでは流石にやりようが無いので対応不可能という事で終了。 image-modeのように Emacsの tempバッファを介してサムネイル生成コマンドに渡せれば リモートファイルでもイケるかも知れませんが、バックグラウンド実行が難しい気がしなくは ありません。思ったよりもうまくいかないものなのかも。

Windows11 に KB5039302 というアップデートが来ていたのですが、どうやら Unicode 15.1の絵文字に 対応しているらしいというのを知りインストールしてみたり。 🍄‍🟫(brown mushroom)や 🍋‍🟩(lime) などが表示できるようになったのですが、 なぜか ⛓️‍💥(broken chain) が Emacsでは表示できないようだったり。 確認したのは Emacs29.4なのですが、一応 admin/unidata/emoji-zwj-sequences.txt は 15.1絵文字に対応したものに入れ替えてあって、 ファイルに記された 🍄‍🟫 や 🍋‍🟩 は表示できているのに ⛓️‍💥 だけがダメという状況。なんでだ？🤔 Edgeで admin/unidata/emoji-zwj-sequences.txtを 表示してみると ⛓️‍💥 の表示はイケてるので、 やっぱりEmacs側の問題に見えます。
Emacs30系ならイケるのか？と思い、30.0.60も動かしてみたのですが、 やっぱり ⛓️‍💥 の表示はイケませんでした。

Emacsで ⛓️‍💥 の表示がイケてない件。どうやら絵文字フォントの設定の問題のようです。 うまく表示できていないところを describe-char で調べてみると、「Segoe UI Symbol」で 表示されていました。⛓️‍💥は「⛓」と「💥」の合字なのですが、「⛓」は symbolに分類されているようで、 symbolは「Segoe UI Symbol」で表示するようにしていた為、 合字も Segoe UI Symbol で表示しようとしてうまく表示できない....という流れではないかと 推測しています。そこで、「⛓」だけ「Segoe UI Emoji」で表示するように文字設定してみたところ、 うまく ⛓️‍💥を表示する事ができました🙂。絵文字の設定ムズ過ぎる🥺。
ただ、「⛓」は単体だと symbolかも知れませんが、VS16を加えた「⛓️」は絵文字の方になります。 前述のようなフォント設定を行なってしまうと「⛓(VS16無し)」も「⛓️(VS16有り)」も 「Segoe UI Emoji」で表示されるようになってしまいます。 ⛓️‍💥は「26D3 FE0F(VS16) 200D(ZWJ) 1F4A5」と定義しているので、絵文字の方の「⛓️(VS16有り)」を 表示するフォントを使うって判定を行なうのじゃないのかなぁ？とは思ったりも。 少なくとも、Edgeの表示は使い分けられているように見えます。

テレワーク。遅めに終了。

Emacs30では defadviceが obsolete らしいのですが、いつくかの古いELISPアプリの中で使用されているものがあります。 しかし、どうやって直せばよいのかよく判らない。

先日の TRAMP接続ができなくなってしまった件。-Qで起動してもダメで 何故だ？という感じ🤔
もう少し調べてみると、plinkはダメなのですが sshxやscpxは大丈夫だったり。むーん？ むしろ plinkで1回はイケたというのが説明が付かない。
ふと、lisp/net/tramp-sh.elの中にある 関数tramp-ssh-controlmaster-options を 29.4 のものに scratchバッファで置き換えてみたところ接続できるな....。 なぜこの関数かと言うと単純に diffで差分を取ってみたところ 何やらplinkの時の処理が付け加えられていた為です。 30.0.60の関数に再度 scratchバッファで置き換えると接続出来なくなり、また 29.4のものに 置き換えると接続できる。ますます 1回はイケた説明が付かない....😓 ただ、何かしら 関数tramp-ssh-controlmaster-options が影響しているのが判っただけでも 手掛かりになるかも知れない。

テレワーク。早くもなく遅くもなく終了。

Emacs30.0.60で 29.4以前の .emacs設定だとなぜかエラーになったり、 上手く動かなくなったりしている所の原因を調べたり。

• flymake-proc-allowed-file-name-masksという変数が無いと怒られる。 29.4まで特に設定していなかったのですが、.emacsに「(require 'flymake-proc)」を追加して解消。
• 「(require 'flycheck)」すると flycheckなど無いと怒られる。 requireする時点でなぜか load-pathが空で パッケージが見えなくなっている。 仕方ないので load-pathに手動で足して解消。パッケージ管理の意味無し😓
• lisp/progmodes/flymake.elの 関数 flymake-show-buffer-diagnostics の挙動が変わっている。 これまでカレントウインドウに被せるように表示されていたのが、カレントウインドウの下の方に 分割表示されるようになったようなのですが、分割表示を自前で実現していたので多重に ウインドウ分割処理されて意図したウインドウレイアウトにならなくなってました。 29.4の関数を別関数名にして .emacsに直定義してみました。 新しい flymake-show-buffer-diagnostics をそのまま使えばよいかとも思ったのですが、 ウインドウの高さを設定できないのがイマイチだったので当面自前で対応する方向で。

• 一度はできていたTRAMP接続が なぜか出来なくなった。 emacsを一度閉じて 再度立ち上げて リモートマシン接続しようとするとなぜか接続に失敗。以降、何度再実行しても やっぱりダメ。前述状態になった後に、emacs-29.4を別途立ち上げて接続するとそちらは繋がる。 emacs-30の方が何かしらの原因でTRAMP接続出来ない状態にスタックしてしまっている。 なんだこりゃ？🤔

テレワーク。気持ち早めに終了。

Emacs30.0.60の src/w32image.c をCygwinでコンパイルするとコンパイルエラーになる件を強引に コンパイルだけ通るようにしてみたり。試しにimage-diredを実行してみたのですが、 全然関係無い所のELISPの方でエラーしているようだったり。調べてみたらimage-diredに対するパッチが リジェクトされていたのを手で直したつもりだったのが不十分だったり。修行が足りません🥺

image-diredで確認しようとすると設定が色々面倒臭かったのですが、 w32image-create-thumbnail というELISP関数として実行可能になっているのを知り 単体実行して確認してみたり。 結果から言うと、CygwinファイルパスからWindowsファイルパスへの変換対応すれば一応動いたり。 ただ、サムネイルのサイズを 128x128 とした場合、元画像のアスペクト比を無視したストレッチ画像になるので、 それなりに設定をした ImageMagickの convertに比べると大分イマイチなサムネイル画像が生成される感じです。 ImageMagickの使えるCygwinでは、今の所 メリットは無いというのが正直な感想。
あと、拙作のwrapped_convertでリモート画像ファイルのサムネイル生成に対応していたりするので、 ローカルファイル限定になるのは機能的にレベルダウンしてしまうというのもあります。

C言語の関数に 文字列を比較する stricmp()って関数がありましたが、現在は strcasecmp()って 関数に代わっているのを知ったり。ほぅ....

Emacs30のブランチをpullしてみたら、Cygwinのw32ビルドで harfbuzzの DLLがロードできていない バグが修正されてたり。

テレワーク。早めに終了。

今日時点での Emacs 30.0.60のビルドを試してみたり。 ELISPの一部のパッチやconfigure.acのパッチがいくつかリジェクトされたものの、ほとんどのパッチは リジェクトされずに当たるようだったり。で、デフォルトでネイティブコンパイルが有効になるので、 ひとまず「./configure --prefix=/usr --with-w32 --with-imagemagick --with-native-image-api --with-native-compilation=no」 で configure＆makeしてみたところ、w32image.c内で使用している関数のリンクに失敗。 30系で GDI+を使ってサムネイル生成を行なえるようになったみたいですが、Cygwinでのビルドに対応できていない感じ。 ちょっと弄ってビルドエラーを解消できる感じではなかったので、 一旦「./configure --prefix=/usr --with-w32 --with-imagemagick --without-native-image-api --with-native-compilation=no」 で native-image-api 無しでビルドしてみたところ、ひとまず emacs本体はビルドできたり。 そういや忘れていたのですが、リリースアーカイブじゃないと .elcもビルドしなくてはならないんだった。 ほどなくしてビルド完了。
で、起動してみるのですが、flymakeやflycheck絡みでこれまでの設定ではエラーするようになったり。 原因がすぐには判らなかったのでバージョン分岐コードを差し込んでひとまずスキップしてみたところ起動できたり😃。 MS-IMEでの入力やカラー絵文字の表示は大丈夫そうで、いきなりズッコケたりはしない模様。 という訳で、何やらエラーするようになったものをぼちぼち調べてみるかという感じ。

テレワーク。早くもなく遅くもなく終了。

もう少し余裕があるかと思いきや、Cygwinパッケージの emacs 29.4がもう出てる😓....
という訳で「Emacsの雑記」を更新しました。 29.4への対応となります。御参考まで。

昼前起床。

掃除したり。

Emacs 29.4向けパッチの準備。 29.3の時は リモートファイルをimage-diredするとハングするという不具合が急に発覚したため、 ゴタゴタしましたが 今回はひとまず大丈夫そう。

ついに Emacs 30のブランチが生成されたもよう。 約3週間ほど前に、その週のうちくらいにブランチが作られそうな感じ に思っていたのですが 意外と時間がかかった気も。29.4のほとぼりが冷めたら30系のビルドを試してみよう...。 それにしても、毎度 前ぶれ無くいきなり来る感じがするのですが、こんなもんなんだっけ？

起きたら午後もいい時間。寝すぎ。

そういえば set-input-methodで W32-IME以外の IMが指定されているとき、 半角/全角キーで切り替えできるんだっけ？と思ったのですが、切り替えできないようになってました。 結局 MS-IMEはアプリの管理下に無いものだと考えるのであれば、同調できないという仕様にしてしまう 考え方もあるのかもなと思ったりも。後ろ向きかも知れませんが😅。 先日記したように、IMEを制御しない日本語キーボードだけに存在する特殊キーとしてON/OFF状態だけが 取れるような制御できるならば、Emacsの管理下で半角/全角キーや変換キーや無変換キーを バインドすることができて、多分問題回避できるような気がするけどなぁ？とは思ったりも。
という訳で、思ったよりも対応が面倒くさい気がしてきたので、半角/全角キーでときどき切り替えに失敗するのは こういうもんだという方向に諦め気味です😓。

Emacs 29.4がリリースされた！？(Emacs 29.4 released) セキュリティアップデートらしい。メインはorg-modeの仕様変更っぽいけど、こまごましたバグ修正は 含まれているみたい。それにしても 29系は なぜかリリース頻度が高くて油断ならない....

IME/その他パッチ をあててビルド。configureのパッチが一部リジェクトされた以外はイケてそう。 ちょろっと使ってみた範囲ではいきなりズッコケたりはしなさげ。
一応ビルドはできるのですが、configure実行途中でメッセージにスクリプトのエラーが混じっているみたい。 Cygwinパッケージの autoconfは 2.72なのですが、それで configureを再生成すると イマイチな状況になるみたい。Emacsのmasterブランチに 「Port better to Autoconf 2.72」 て変更が加えられているようだったので取り込んでみたら大丈夫そう。 Cygwinパッケージがリリースされるまでの間にテストしてみよう。

テレワーク。気持ち遅めに終了。

半角/全角キーを押すとキーそのものの down/up ではなくて、VK_OEM_AUTOとVK_OEM_ENLWが トグルになるようなキーコードが送られてくるようです。 いずれかの upが先に来て、その後に続けて VK_PROCESSKEY のdownが送られてくるという感じみたい。 その後に wParamが IMN_SETOPENSTATUS の WM_IME_NOTIFYメッセージ が届くので、その時の imeの状態に応じて何かするように書くものみたいです。 半角/全角キーを押した場合は、WM_IME_NOTIFYメッセージを受けて Emacs本体に仮想的なキーイベント として VK_KANJI をポストする という順番になるようです。 キー押下→IME切り替え→Emacs本体処理 というイメージかなと。
一方、C-\ にバインドしているような場合は、キー押下のイベントをEmacs本体のキーイベントとして 受け付けたのち、IMEの状態を変更する関数を実行すると wParamが IMN_SETOPENSTATUS の WM_IME_NOTIFYメッセージ が届く という順番になっているようです。この場合は、Emacs本体の辻褄を合わせた上で IMEの切り替え が行なわれるので、キー押下→Emacs本体処理→IME切り替え というイメージかなと。
半角/全角キーの場合でも、普通のキーと同じく Emacs本体のキーイベントを受け付けたら 自力でIMEの状態を変更すれば 大丈夫だったりしない？と思った訳ですが、 IMEの制御をしないただのキーの状態だけが取れるようにする方法が判らず。できないのかも知れません。 キーの押し下げメッセージとWM_IME_NOTIFYメッセージの間に他のイベントが入る事ができて しまうようなのが話を難しくしているような気も。

テレワーク。早めに終了。

調べ事。まだよく判らず。

テレワーク。気持ち早めに終了。

調べ事。うーむ、よくわからん。

テレワーク。気持ち早めに終了。

そういえばlibjxlのv0.10.2てのが3月8日に リリースされていたのですが、v0.10.0から頻繁にアップデートされていたので、 静かになるのを待とうと思っててそのまま忘れていました😅。 その後変化がないなぁ？というのに気づいたので試しにビルドしてみたり。 で、以前v0.10.0が出た時にCygwinでビルドした 実行ファイルはMinGWでパッケージインストールしたもの(v0.9.1でしたが)よりも実行速度が 遅いという現象が見られたのですが、今回ビルドしたものは v0.10.0で見られたような 露骨に遅い現象は起こりませんでした。

JPEG XL encoder v0.10.2 b7582cee [AVX2,SSE4,SSE2]

| -e N |      real |      user | file size | 備考     |
|------+-----------+-----------+-----------+----------|
| -e 1 |  0m1.695s |  0m1.875s |   5268465 |          |
| -e 2 |  0m1.713s |  0m2.531s |   5268465 |          |
| -e 3 |  0m1.792s |  0m2.171s |   4882877 |          |
| -e 4 |  0m1.896s |  0m2.171s |   5048317 |          |
| -e 5 |  0m3.220s | 0m10.671s |   5559389 |          |
| -e 6 |  0m5.212s | 0m17.640s |   5540527 |          |
| -e 7 |  0m5.383s | 0m19.203s |   5581861 |          |
| -e 8 | 0m57.959s |  1m6.109s |   5403698 |          |
| -e 9 | 1m26.178s | 1m32.984s |   5408195 |          |
|------+-----------+-----------+-----------+----------|
| jpeg |           |           |   6408555 | q 90     |
| png  |           |           |  36531643 | original |

テレワーク。早くもなく遅くもなく終了。

あまりの眠さに急速停止。

AM中に起床。

調べ事。「半角/全角キー」を押した時の Windowsメッセージを調べてみたり。 まだよく判っていませんが、普通のキーとはちょっと違うっぽい。 てか、単純に VK_KANJI ってコードが送られてくる訳では無いらしい。

昼前起床。

掃除したり。

調べ事。IMEパッチでは Emacsの本体側から発生するキーイベントで IMEをON/OFFする経路と、 「半角/全角キー」や「変換キー」や「無変換キー」を押すと WM_IME_NOTIFY というWin32APIの メッセージが送られて来て、IMEのON/OFFが切り替わる経路があります。 以前より、前者のEmacs本体側から IMEをON/OFFする方は問題無いのですが、 後者の WM_IME_NOTIFYメッセージにより IMEのON/OFFが切り替わる方はちょいちょいイベントが リジェクト(?)される事があって、うまく切り替わらない事があります。 まだよく判っていませんが、なんとなく後者はメッセージを受けた後に前者のキーイベントに(も？) 置き換えている節が見られていて、二重に処理が行なわれているのではないか？と思ったりも。 単純にキーイベント変換を行なわなければ、うまく動くようではあるのですが、 インクリメンタルサーチ時のcurrent-input-method-title表示が切り替わらないという副作用があってイマイチ。

テレワーク。気持ち早めに終了。

調べ事をして終了。

テレワーク。気持ち早めに終了。

ダンジョン飯のアニメ。最初の方も見逃しで観てたのですが とても面白かったと思います。 本日最終回が放送されたのですが、To Be Continued... はアニメとして続くという意味なのか？ それとも アニメは終わるが物語はまだ続くという意味なのか？ 是非アニメでも〆て欲しいと思ったりも。と記したところでWeb検索したら 第2期の制作が発表されたもよう(参考)。 楽しみ。

ちょろり作業。

テレワーク。早くもなく遅くもなく終了。

ちょろり作業。

テレワーク。気持ち早めに終了。

ちょろり作業。ひとまず大丈夫そう。

bashコマンドラインで何気に「C-/」を押したら行編集の UNDOができるというのを知りました。 知らんかった.... 因みに使用している keymapは emacsスタイルです。

テレワーク。早くもなく遅くもなく終了。

Emacsを起動するときに -Qオプションを付けると標準のELISPパッケージ以外は読み込まれません。 その状態で「M-x load-file」で ~/.emacs を読み込むと -Qオプションを付けないで 起動したのと同じになるのだっけ？と思い試してみた所、例えば /usr/share/emacs/site-lisp には load-path が通っていなくて そこに入っているELISPを「(require 'なんとか)」すると 「なんとか を開くことができない」と怒られました。 ここで疑問なのですが、-Q起動だと足されず、.emacsを読み込むと暗黙のうちに追加されている パスってのは、一体どこで足されているのだろうか？
正確に読めてはいませんが、emacsの起動オプションの中に --no-site-lisp というのがあり、 -Q は「-q --no-site-file --no-site-lisp --no-splash --no-x-resources」を指定したのと 同じようです。--no-site-lispが指定されているか否かで インストールするパスに応じて /usr/share/emacs/site-lisp だったり /usr/local/share/emacs/site-lisp だったりを追加しなかったり 追加したりするっぽい。

AM中に起床。

ちょろりお出かけ。

手持ちのD言語コードをビルドするのにMakefileを使っているのですが、 以前、dmd/ldc2をCygwinのEmacsのflymakeで使う為のスクリプトを作成したので、 チェックに使用するコンパイラを MinGWクロスgdcから dmdに変更してみていました。 ついでに gcc-11.3や11.4 では Cygwin上で MinGWクロスgdcをビルド＆使用できるようになっていたのですが (参考)、ちょろっと試してほったらかしにしていたので、 そちらでもビルドできる事を確認してみたり。ただ、コードの本体は dmd/ldc2/gdc いずれでもビルドできる のですが、外付けライブラリのビルドができない場合があって面倒臭いところです。

AM中に起床。

掃除したり。

ノートPC(Windows11)でちょろっと作業して、シャットダウンしようとしたらなにやらWindowsUpdateが来ているようだったり。 5月にアップデートしたし、6月のアップデートはまだなのですが、23H2の累積的アップデートってなってて何だっけ？ とは思ったりも。再起動を要求された状態なのでインストールするのですが、 月例以外でアップデートする事なんて今までなかったように思ったりも。

テレワーク。早くもなく遅くもなく終了。

ちょろり確認。イケそう。

テレワーク。気持ち早めに終了。

調べ事をして終了。

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

テレワーク。気持ち早めに終了。

3日ほど前に Emacsのorg-modeの9.7がリリースされてたらしい。 といっても、公式ページでは ソースコードのアーカイブが置かれなくなって久しいので、 ページを見ても新しくなっているのに気づけないのですが。 Emacsの 30系リリースには org-modeの 9.7.xが取り込まれるんじゃないかと思われます。

なにやら近々 Emacsの 30系のブランチが生成されるみたい。29の時は ブランチした途端に tree-sitterがボロボロだってのが発覚して整うのに随分時間がかかった気がするのですが、 30ではどうかなぁ？

テレワーク。気持ち早めに終了。

Web巡回して終了。

AM中に起床。

雨が降る前にちょろりお出かけ。

そういやEmacsの vtermを起動した状態で インプットメソッドを変えれば色んな文字の入力ができるんじゃね？ と思ったり。で、試してみるのですが、例えば「chinese-py」とかはうまく動くようですが、 「japanese」だとうまく文字が入らないようです。IMEパッチだと外から直接文字をペーストしている 感じで動作するので一応 日本語文字入力は可能なようです。 他にも、キーボードマクロ実行をターミナル入力に適用することもできるようですが、出力を待って入力 している訳では無いようなので 微妙な感じです。上手く使えば良い感じのことができそうな予感はしますが 果たして？🤔

昼過ぎ起床。寝すぎ。

掃除したり。

GUIの Emacsではフルカラー表示が可能です。その上で動くvtermもフルカラーで表示が可能なハズだよなぁ？ と思いましたが256色設定だなと思ったので 方法があるのかしら？と思い調べてみたり。 Webでは情報を得る事ができなかったのですが どうやら応用の範囲内らしい。以下のような感じでイケるようです。

1. 以前知った方法で xterm-24bitというTERM設定が行えるようにしておく。
   (やり方を示したinfoをWeb上で見つけられなかったのですが、元になるEmacs-26.3の doc/misc/faq.texi の この辺)
2. GUI Emacsを起動後、vtermを起動する。
3. vterm起動したbashの環境変数TERMを「export TERM=xterm-24bit」でxterm-24bitにしておく。 これでvterm上はフルカラー表示可能な状態になっているようです。
4. 「COLORTERM=truecolor emacs-w32 -nw」で vterm内で Emacsを -nw 起動します。 起動されたEmacsはフルカラー表示されているという感じです。