最近の出来事

2026/05/17

AM中に起床。

掃除したり、洗濯したり。

MS-IME時の再変換イベント。今のところ、Emacsの外側で半角/全角キーを押してIMEをON/OFFすれば、 いきなり再変換を発動させても大丈夫そうです。 しかし、Emacs内からIMEをON/OFFした後、何かしら文字入力して変換窓が開くようなことを行った後に、 再変換を発動させても 変になります(変換窓が開かずキーイベントが掴まれてしまう)。 つまり、事前に入力して変換窓を開いても再変換時の状態が修正される様子は見られませんでした。 ただ、インクリメンタルサーチを起動し、その中でIMEをONにして、なにかしらの文字をいれて確定させた後、 インクリメンタルサーチを終了してから 再変換を発動すればうまく変換窓が開くというパターンを一つ見つけました。 この手順の中に何かしら状態を初期化する要素が含まれているのではないか?と考えたのですが、 それが何なのかまでは突き止められず。 インクリメンタルサーチではミニバッファにカーソルが移動するので、その時にカーソル位置やフォントが 変更される事で位置情報が修正されるのだろうか?と思ったのですが....?🤔

そういや日本語文字じゃない文字列を再変換したらどうなるだろう?と思い、 Emacsの view-hello-file の中からアラビア語だとか適当に選んでみたところ、 表示はされるけど文字としての認識だったり(絵文字もそんな感じ)、トーフになったり、 場合によってはハングするみたいです。因みに試したのはCopilot Keyboardのみです。

2026/05/16

AM中に起床。

Emacsの再変換コード。デバッグコードを取り払ってみたり。 また、いくつかコードを有効にするか否かを切り替えるdefineがあったのですが、 今となっては使用できないと思われる切り替えも取り払ってみました。 かなり盛大に弄ってしまったのと、まだMS-IME時にいきなり再変換したときの不具合も残っているので、 しばらくテストと実験が必要かも。

MS-IME(新しい方)やCopilot Keyboardでは、変換キーや無変換キーの挙動を変えられるようになっています。 現在、無変換キーをIME-オフに、変換キーをIME-オンに設定しているのですが、 再変換のことを調べていて、そういえば変換キーはもともとは再変換に割り当たっていたなぁ? と思い出しました。割り当てを変えるくらいなので、再変換は全く使ったことなかったのですが、 実際に使っている人ってどれくらいいるのだろうか?とは思ったりも。 というのも、誤変換を直すことよりも誤入力を直すことの方が圧倒的に多いため、 再変換を使って誤入力の修正を行うよりも、結果的に入力し直した方が早いという場面しかない ように思えるからです。Webで検索してみると「仕事術的な活用で時短がなんとか....」みたいな 記事で紹介されている例が多いように思うのですが、効率アップになるのかは甚だ疑問に思います。 それよりも間違えずにキーボード入力できる方が良い (言い換えるとキーボード入力で間違いまくるのはそもそも効率が悪い)とは思います。

MS-IME時の再変換イベント。Emacsを起動した直後、ウインドウ(フレーム)を動かさずに そのまま再変換を発動すると大丈夫だけど、ウインドウを一旦動かしてから再変換を発動するとダメに なるっぽい。 随分前に、ウインドウを一旦動かさないとIMEがオンにならない という話がありました。その後、 事象が緩和されたので対処療法を入れてましたが、更にその後に行われた Windows10のアップデートで 事象自体が自然消滅したことがありました。 今回はウインドウを動かすとダメという事で、前とは逆ですが似たような話があるのかなぁ?という感じです。 ウインドウを動かした場合でも、「半角/全角キーでIMEをONにしてから再変換をすれば大丈夫(以降も問題無し)」なので、 MS-IME内の何かしらのフォーカスが失われているのが原因だろうとは思うのですが、 それをどうにかする方法が見つかっていません。 ピンポイントな事象なので、最悪原因不明のままでも対処療法が見つかればラッキーなのですが。

そういえば、「以前のバージョンのMS-IME」での再変換はどうか?と思い確認してみたところ、 (便宜上)現在のMS-IMEで起こっている、いきなり再変換すると変になる現象は発生しませんでした。 結局変なのは現在のMS-IMEだけで、以前のMS-IMEもCopilot Keyboardも問題無しという模様が付いてます。 久しぶりに以前のバージョンのMS-IMEを使用したのですが、やっぱりShiftキー単押しで英数とローマ字が 切り替えられるのは便利です。現在のMS-IMEでは開かなくなった辞書登録も、 以前のMS-IMEでは開くことができるのも変わらず。 現在のMS-IMEは唯一変換候補窓に絵文字がカラーで表示される点だけが良いのですが、 Copilot Keyboardではモノクロ表示に退化してしまっているのはなぜなのだろう?と思わなくはありません。

Emacs31。まだソースアーカイブがリリースされる状況ではなさそうなので、 gitリポジトリの31系ブランチにパッチをあてておいたり。ソースアーカイブがリリースされるようになるまでは、 時々pullしてビルドや動作確認する感じで。実験は別にクローンしたディレクトリ下で行なうようにしてみたり。

2026/05/15

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

再変換。ひとまず余計な実験コードをバッサリ削除して整理してみたり。

MS-IMEの時にいきなり再変換を行うとハング状態に陥るように見える件。 少し前のメモの通り、最小化→元に戻す 操作で復帰はするのですが、 この時の作りでは再変換対象文字列が失われてしまうので、EmacsのUndoで失われた文字列を 復旧させる必要がありました。 今回、再変換の発動時に対象文字列を一時的に保持しておく方法にした事により 「もう一度再変換を発動させる」ことで、ハング状態に陥った風に見える時の変換対象文字列 の再変換窓が開き、操作が行なえるという復旧が可能になりました。 とはいえ、なんとかならんかなぁ?と思うのでもう少し反応する要素が無いかを探ってみたい と思います。因みに、Copilot Keyboardではいきなり再変換を発動しても今のところ問題は無さそうです。

そういえば先日、再変換の処理で変換が確定してから元のデータを削除するような実験を行ったとき、 変換編集窓の表示位置が「これじゃない」感じになりました。変換窓の開く位置はカーソル位置になるため、 範囲選択した領域を再変換するようなケースを考えると、選択領域の最初の位置では無く、カーソルのある 最後の位置になる為、位置がこれじゃないという感じになりました。 再変換を発動した時に選択の始点と終点を入れ替えて、カーソル位置を始点に移動できれば解決 できるんだけどなぁ?と思って位置を交換する方法が無いかをGoogleAIに聞いたら、 位置交換の方法の一つに「exchange-point-and-mark」というのがあって「C-x C-x」に割り当たっている というのを初めて知りました。領域選択した所で「C-x C-x」を押せば始点の位置にカーソル移動できるとともに、 選択開始位置も変更できるので、開始位置を間違えた場合に選択し直す手間が無くなるなぁと いう発見がありました。矩形選択の時も使えるのでなかなか良いかも。

2026/05/14

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

再変換。ひとまず「msg=WM_IME_REQUEST, wp=IMR_RECONVERTSTRING」メッセージが届く可能性がある 期間はバッファのデータは更新せず、変換確定したら削除するようにしてみたところ、 挙動不審にはならなくなったような気が。でも、変換編集窓の表示位置がこれじゃない感。
もっと雑に、初回に生成した RECONVERTSTRING構造体の内容と文字列を 一時メモリに保持しておいて、 Emacs側からはデータを削除、二回目以降は一時メモリに保持した内容を丸コピーでいいんじゃないか?と 思って試してみたり。イケたような気がしたけどハングるな....🤔。 でも、挙動不審に思えていたのも、そういうものだという事が分かったので、やりようがあるように思えてきました。

2026/05/13

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

全く気付いていなかったのですが、Inkscape 1.4.4がリリースされていたらしい (アナウンス)。 バグフィックスがメインみたい。

再変換。 「msg=WM_IME_REQUEST, wp=IMR_RECONVERTSTRING, lp==0; 必要なメモリサイズの問い合わせ」が二回送られてきたり、 「msg=WM_IME_REQUEST, wp=IMR_RECONVERTSTRING, lp!=0; 再変換対象文字列の問い合わせ」が二回送られてきたりすることが、 最小コードでも発生するようだったので、そんなことがあり得るのか?というのをGoogleAIで聞いてみたら 「あり得る」という回答で えー!?🥺 と思ったり。 「必要なメモリサイズの問い合わせ」の方はもう面倒臭いので、再変換を受け付ける文字数はどうやら50文字まで のようなので、それを最大と想定して常に最大サイズを要求する事で対応できると思うのですが、 「再変換対象文字列の問い合わせ」の方は今の再変換の実装だと1回目の問い合わせで元の文字列を 削除してしまうので、もう一度問い合わせられたら同じ文字列を再設定できないという感じになっています。 面倒臭いのは再変換の確定は WM_IME_COMPOSITION で送られてくる、つまり再変換がトリガとなって 指定された文字列を変換したのか、キーボード入力がトリガとなって指定した文字列を変換したのかが 区別がつかない為、後で元の文字列を削除するというのが簡単にはできません。 因みにMS-IMEは「必要なメモリサイズの問い合わせ×2, 再変換対象文字列の問い合わせ×1」なので、 今の再変換の実装でうまく動くのですが、 Copilot Keyboardは「必要なメモリサイズの問い合わせ×1, 再変換対象文字列の問い合わせ×1だったり×2」だったり するため、「再変換対象文字列の問い合わせ×2」だった場合におかしなことになっているという感じです。 単純に「なにこれ?面倒臭い」という感じに思えます。
複数回通知される事はMicrosoftのドキュメントに記されてるのか?と聞いてみたら「暗黙の仕様」なのだそうな🥺。 確かに、「lp==0とlp!=0の それぞれの場合に どうしなくてはならない」は記されていますが、 それぞれ1回しか通知しないとは言ってないし、このメッセージをトリガにして他の処理(例えば元の文字列を削除しておく)を 入れてステートフルにしても問題無いとも言っていない......と、いわれればそうなのですが、モヤっとはします🤔

2026/05/12

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

再変換。先日 MS-IMEの時にいきなり再変換を行うとハング状態に陥ると記しましたが、 確かに固まるものの一度Emacsをタスクバーなどから最小化→元に戻すという操作を行なうと 復帰するようです。雰囲気的に再変換の候補ウインドウが何かしらの理由で開かないのですが、 それによりフォーカスが固定されてハング状態っぽくなるものの、最小化などを行なうと フォーカスが復帰し、ついでに再変換も可能になるという感じに見えます。 何かしら初期化を行なえば良いのか?とも思ったのですが、反応する方法を見つけられず。
Copilot Keyboardの方は先日も記した通り、何故か再変換イベントが二回発生する事があり、 こちらも原因が分かっていません。むーん🤔

2026/05/11

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

再変換。カーソル位置が変になら無さそうにはなったものの、 MS-IMEの時に日本語文字を入力した後、再変換を行うとハング状態に陥る現象に見舞われています。 再変換を行なう前に「半角/全角キー」でIMEを一度ONにしてから再変換を行なうと大丈夫っぽい。 Emacs側からIMEをONにしてもダメ。Emacs側からのIMEをON/OFFは ImmSetOpenStatus()を実行する事で 行なっていますが、これでダメというのには困った....🤔。 でも、Copilot Keyboardでは大丈夫。急に形勢が逆転してしまってます😓。

弄っていると何故か再変換イベントが二回発生するケースがあり、1回目に選択した領域が 消滅して動きが変になったりしています。なんでこんなに挙動不審になるのかよくわからない。

2026/05/10

AM中に起床。

掃除したり。

再変換。MS-IMEの方もサイレント落ちしたりと微妙な感じだったので、まずはそちらが安定して 動作してから Copilot Keyboardの方を見た方が良いかなと思ったり。 絵文字を食わせるとダメになったり、長い文字列を再変換しようとすると動きが変になったりしたのを 直してみて安定してきた感じにはなりつつあるのですが、Copilot Keyboardで同じ事をやるとやっぱりダメ。 うーむ🤔。

実験用の最小コードでリコンバージョンを試してみたところ、少し反応が見られたり。


うーん、なんか正解がよくわからない。

Emacsで処理を潰しながら何が影響しているのかを見ていたら、急に MS-IME も Copilot Keyboard も 再変換が動くようになったり😓。 まず、「msg=WM_IME_REQUEST, wp=IMR_RECONVERTSTRING, lp!=0」の組み合わせが、 なぜか2回以上発生する件。処理自体は w32_get_ime_reconversion_string() という関数で行なっているのですが、 ここでは Emacs上でマークされた再変換対象文字列を取り出して、lpで渡されてくる RECONVERTSTRING* の領域を設定&再変換対象文字列のコピーを行なった後、Emacs上の再変換対象文字列を削除しておく というのが大まかな流れになります。 元のコードでは ここで更に ImmSetCompositionString()で SCS_SETRECONVERTSTRING で lpで渡されてくる RECONVERTSTRING*をセットする処理が行なわれていたのですが、どうやらこれを実行 すると 「msg=WM_IME_REQUEST, wp=IMR_RECONVERTSTRING, lp!=0」の組み合わせを通知してしまうようで、 見かけ上再帰的に実行されてしまう事になっているようでした。これが Copilot Keyboardではダメなようですが、 MS-IMEでは何故か大丈夫なようです。 GoogleAIで IMR_CONFIRMRECONVERTSTRING の処理について聞いてみても、再変換文字列に関する情報を セットして「return reconv->dwSize;」するだけという事だったので、余計な処理を削ってみたら なんとなくMS-IMEもCopilotKeyboardも 再変換が機能するようになった.....という感じです。 ただ、カーソル位置が変になることがあるので、まだダメです🥺

2026/05/09

AM中に起床。

IMEパッチのコードで再変換を行う RECONVERTコードってそういや有効にしてビルドしていないなぁ? と思い、少し前のEmacs masterブランチでRECONVERTを有効にしてビルドしてみました。 以前、31系で大量のワーニングが出るようになったのを 直したのですが、RECONVERTの部分は直していなかったので大量のワーニングが出るままになっていたり。 ワーニングはさておき、そのまま実行してみたら再変換を発動するのと同時にサイレント落ちしたので 原因を調べて直してみたり。 で、MS-IMEではどうにか動くようになったものの、Copilot Keyboardでは挙動が不審な状況です。
挙動が不審というのは、再変換を発動すると変換候補窓が一瞬現れてすぐに消えてしまい、 何かしらキー入力は受け付けるのですが、Emacsに突き抜けている感じになります。 ESCキーで脱出すると変な編集結果が反映されてしまいます。変になるパターンがいくつかあるようなのですが、 弄っているとサイレント落ちする場合もあります。 一応、メモ帳などでは Copilot Keyboardによる再変換は機能するようなのですが、 何か足りないか、何かしら余計なことをしているか、Copilot Keyboardのバグなのか..... 今のところアテがありません。

先週、「おこなって」は「行なって」は許容で「行って」が本則の 書き方だというのを知りました。そういや「かわって」は「変わって」と「変って」とだとどうなんだ? と思って調べたら「変って」が許容で「変わって」が本則らしい。

| 読み       | 本則     | 許容     |
|------------+----------+----------|
| おこなって | 行って   | 行なって |
| かわって   | 変わって | 変って   |

「行って」はそれだけ見ても「いって」と「おこなって」の区別が付かない方が本則になっているのに、 「変わって」は、より読み違いにくい方が本則になっています。単純になんでだ?と思います。
因みに「変って」はEdgeもVOICEVOXも「へんって」とは読まれず。 でも、「この状況は変って思いました」はEdgeもVOICEVOXも「このじょうきょうはかわっておもいました」 となり「このじょうきょうはへんっておもいました」とはなりませんでした。

再変換。色々反応を見てみるもこれといったものは掴めず。それよりもMS-IMEでもちょいちょい サイレント落ちする場合があって、何がなんだかよくわからなくなったりも。

2026/05/08

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

予定通りEmacs-31のブランチが作成された模様 (アナウンス)。

調べごとをして終了。

2026/05/07

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

調べごとをして終了。

2026/05/06

AM中に起床。

随分前に取り溜めていた録画を消化。

2026/05/05

AM中に起床。

先日の捨てられているメッセージ。 どんなメッセージが捨てられていたのだろうか?と思い、デバッグprintを仕込んでみたところ、 以下のようなメッセージが捨てられていたようでした。


挙動から察するに 0xc05a が捨てられていた事が Copilot Keyboardで Copilotの回答(Copilot Answer) が開かなかった原因だろうと考えられるのですが、 GoogleAI回答によれば HWNDが0のメッセージは そもそも DispatchMessage() では処理されないもの とされているようです。 しかし、実際には DispatchMessage に食わせることで Copilotの回答 が開くようになったのは 挙動としてなんかおかしくね?という気がします。

Emacsのsrc/w32fns.cを git log で遡ってみたところ、記録上は最初にコミットされた1995年11月7日時点で 既に以下のような構造だったようです。

:以下抜粋
+DWORD
+win_msg_worker (dw)
+     DWORD dw;
+{
+  MSG msg;
+
+  /* Ensure our message queue is created */
+
+  PeekMessage (&msg, NULL, 0, 0, PM_NOREMOVE);
+
+  PostThreadMessage (dwMainThreadId, WM_EMACS_DONE, 0, 0);
+
+  while (GetMessage (&msg, NULL, 0, 0))
+    {
+      if (msg.hwnd == NULL)
+       {
+         switch (msg.message)
+           {
+           case WM_EMACS_CREATEWINDOW:
+             win32_createwindow ((struct frame *) msg.wParam);
+             PostThreadMessage (dwMainThreadId, WM_EMACS_DONE, 0, 0);
+             break;
+           case WM_EMACS_CREATESCROLLBAR:
+             {
+               HWND hwnd = win32_createscrollbar ((struct frame *) msg.wParam,
+                                                  (struct scroll_bar *) msg.lParam);
+               PostThreadMessage (dwMainThreadId, WM_EMACS_DONE, (WPARAM)hwnd, 0);
+             }
+             break;
+           case WM_EMACS_KILL:
+             return (0);
+           }
+       }
+      else
+       {
+         DispatchMessage (&msg);
+       }
+    }
+
+  return (0);
+}
:

現在はもっと処理するメッセージが増えていたり DispatchMessageAと DispatchMessageWを 使い分けていたりしますが、msg.hwnd==NULL での switch (msg.message) の default:無し は今も同じです。パッチとしては default:で DispatchMessage()を実行するという感じに したのですが、見る人によっては「なにこのパッチ、意味あんの?」って思われるかも知れません。
そもそも HWNDが0のメッセージはスレッドメッセージとして扱うしか無いのですが、 あずかり知らないものは処理できないし、DispatchMessage()で処理されないのであれば、 捨てられても問題になってはならないと思われます。 やっぱり Copilot Keyboard 側のバグじゃないかなぁ? 少なくともアプリ側で対応が必要なのは普通はダメだと思います。 ワークアラウンドとしてパッチがあてられるのはEmacsのようなOSSに限られる訳ですし。

先日、Copilotの回答が表示されるようにはなったのですが、長い文章では単語を調べる感じにはならない と記しました。MS-IMEとCopilot Keyboardでは以下のような違いがあるからかもしれません。

MS-IMEとCopilot Keyboardの辞書表示の違い

MS-IMEでは例えば「保証」に助詞をつけたり動詞化した場合でも、辞書表示が行われるのですが、 Copilot Keyboardでは単語変換でしか辞書表示が行われません。長文中の文節変換で 「これで合っているんだっけ?」の確認ができないので、あらかじめ調べておくか一旦文章作成を中断して 調べる必要があります。「ほしょうできない」を文節の長さを変更して「ほしょう」と「できない」に してから「ほしょう」を変換すれば辞書表示されますが、そういうことではないよなぁ?とは思います。 MS-IMEではできていたことなので、Copilot Keyboardでもできるようになるのを期待したいです。

2026/05/04

AM中に起床。

掃除したり。

Emacsで Copilot Keyboard の Copilotの回答(Copilot Answer) が表示されない件を調べたり。 そもそも IME制御を行う最小コードだと、メッセージを処理するWndProcの中に ウインドウを閉じる為だけの WM_CLOSE, WM_DESTROY の処理だけを入れれば、 インライン表示にはなりませんが、IMEのエディタは別ウインドウで表示され、 Copilotの回答も表示されます。そこで、Emacsの方でメッセージを処理している w32fnc.c内の関数w32_wnd_proc()を極限まで削ってみたのですが、それでも Copilotの回答 は表示されず。えー?🤔
もっと上位のメッセージループは 関数w32_msg_pump()の中にあるのですが、 GetMessage()で取得した メッセージ の msg.hwndが NULLか否かで処理が分かれていました。 で、NULLだった場合はいくつかある WM_EMACS_* という自前のメッセージを処理している ようだったのですが、どれでもない場合はそのままループを抜けるようになっていました。 もしかしてこれってメッセージを捨ててることにならない?と思い、DispatchMessage()すると Copilotの回答が表示される事が分かりました。デバッグコードを剥がして修正を適用してビルドしたところ、 所望の動作を行うEmacsになりました😄。 因みにIMEパッチは関係無くてオリジナルのコードの不具合(かどうかはまだ不明)です。 この為、Cygwinパッケージのemacs-w32バイナリ(恐らく公式のWindows用バイナリも)でも Copilotの回答 は表示されませんでした。

EmacsでCopilotの回答表示に成功

実験は Emacsのgitリポジトリの masterブランチで行ったのですが、30.2も同じなので対応。 しばらく普段使いで動作確認してみます。

ところで、Copilotの回答が表示されるようにはなったのですが、長い文章を入力していると 単語を調べる感じにはならないなぁ?とは思ったりも。

Copilotの回答で🔍ボタンを押すと Bingの検索が行われるのですが、キャラクターのチャットの方に 流し込む方法は無いのだっけ?と思ったりも。 単語ではなく文章で入力しなくてはならないので、 長文を特別なキーバインドで決定&流し込み実行する必要はあるかもしれませんけれども。 今のところ、Copilot Keyboardはスキンがキャラクターの見た目と連動しているだけで、 IMEとAIキャラクターが「連携」はしていないなぁ?とは改めて思ったりも。

2026/05/03

AM中に起床。

VOICEVOXの読み方&アクセント辞書登録。 単純な単語の登録は非常に簡単に行えるのですが、前日の「行って」みたいな、どうしようもないのが いくつかあるなぁ?と思ったり。「行」を「くだり」と読まれたり、「値」を「ね」と読まれたりするのは、 「くだり」や「ね」を封印する事にして「ぎょう」や「あたい」を登録したり、 「行末」を「ゆくすえ」と読まれたのは そっちかぁー と思いながら封印したりしてみました。 自分が作成した文章以外を読ませると、ボロボロになるかもしれないな....😓

2026/05/02

AM中に起床。

Ollamaで音声解析ってできるんだっけ?と思ってちょろっと検索してみたところ、 方向は逆ですがテキスト読み上げを行う VOICEVOXという音声合成ソフトの存在を知りました。 GUIを介してテキスト入力や読み上げの編集を行えるのですが、それとは別にREST-APIサーバーとしても 動作するようで、Cygwinだとbashコマンドラインからcurlを介して音声を再生するところまで実行 可能なようです。

| 原文         | ソースを弄ったEmacsをCygwin上で野良ビルドすると大分使いやすくなりました。                    |
|--------------+----------------------------------------------------------------------------------------------|
| Edge読み上げ | そーすをもてあそったいまくをさいぐいんうえでのらびるどするとおおいたつかいやすくなりました   |
| VOICEVOX     | そーすをいじったいーまっくすをしぐうぃんじょおでのらびるどするとだいぶつかいやすくなりました |

知らない単語はともかくとして、Edgeは結構読み違える事があるのですが、 VOICEVOXは読み違いが少ない印象です。 それでもEdgeでは大丈夫な「準備を行ってみました」は「じゅんびをいってみました」になったり、 「読み違える」は「よみたがえる」になったりしました。

VOICEVOXを試すのにCygwinのbashスクリプトで雑に以下のようなのを作成してみました。

#!/bin/bash

speaker_id=2

str=$(printf '%s\n' "$1" | sed 's/ //g')
IFS='。' read -r -d '' -a lines_arr < <(printf '%s\0' "$str")

for line in ${lines_arr[@]}; do
    printf "%s\n" $line
    echo -n $line \
        | curl -s -X POST --get --data-urlencode text@- \
               "localhost:50021/audio_query?speaker=${speaker_id}" \
        | jq '.speedScale=1.3|.volumeScale=2.0' \
        | curl -s -H "Content-Type: application/json" -X POST --data @- \
               "localhost:50021/synthesis?speaker=${speaker_id}" \
               > /dev/dsp
done

exit 0

単純にパイプで繋いでいるだけですが、Cygwinでは/dev/dsp(今となってはレガシーなデバイスファイルのようですが) が使えるので.wavをそのままリダイレクトして再生しています。途中で速度とボリュームをjqで変更しています。 あと、クエリパラメータのspeakerは audio_queryと synthesisの両方に必要みたいです。 気づかず audio_queryの方だけを変えていたのですが、微妙に変化はあるものの思った声の選択になってないような? となりました。

VOICEVOXで読みの辞書登録を試してみたのですが、「行ってみました」は「いってみました」と「おこなってみました」 のどちらになるかは助詞や文脈によります。 手前の助詞が「を」だと「おこなって」の可能性がかなり高いですが、 「と」だと「いってみました」か「おこなってみました」かは近接する助詞だけでは判断が難しく 「旅行に彼と行ってみました」と「準備を彼と行ってみました」の読み分けを 単語登録だけで行うのは無理があります。で、確率の高い「を行って」を「をおこなって」と登録してみたのですが 採用されず。助詞の「を」は後ろの単語とは組にならず手前の単語と組になるようなので、「を行って」には マッチしないという結果になりました。「行って」を「行なって」と記せば「おこなって」にはなるものの、 現代日本語では「行って」と記すのが一般的になっているようです (参考記事)。 よりによって読み方の判断が難しい方が一般的になってしまっているのは機械泣かせだなぁと思うと同時に、 センス無いなぁとも思います。 これまで、誤変換については色々な問題に遭遇することはありましたが、個人的に読み上げを使う場面は無かったので、 今回のように漢字を使っていたとしても、読み方の難しい場面があるとはあまり想像してませんでした。 AIで一旦読みに変換すると精度が上がる例かもしれません。

試しにOllama+qwen3.6:35bで「旅行に彼と行ってみました」と「準備を彼と行ってみました」のそれぞれの 読みを聞いたところ、以下のような回答になりました。

* ** 以下の日本語の読み方を示してください。
- 旅行に彼と行ってみました
- 準備を彼と行ってみました


ご提示の文の読み方は以下の通りです。

- 旅行に彼と行ってみました
  → *りょこうに かれ と いってみました*
- 準備を彼と行ってみました
  → *じゅんびを かれ と いってみました*

---
💡 *補足(より自然な表現について)*
日本語の語順やコロケーション(語の結びつき)の観点から、以下の点をご参考までに申し上げます。

1. *旅行に彼と行ってみました*
   文法的に間違いではありませんが、ネイティブは通常主語や関連する名詞を先に持ってくるため、
   =彼と旅行に行ってみました=(かれと りょこうに いってみました)の方が自然です。

2. *準備を彼と行ってみました*
   「準備を行う」は正しい表現ですが、「〜と行ってみる」という組み合わせは少し不自然に響く場合があります。文脈にもよりますが、以下のように言い換えるとより自然です:
   - =準備を彼としてみましたが=(試した結果、何か分かった・わかった)
   - =準備を彼としましたが=(ただの共同作業)
   - =準備を彼と揃えました/共同しました=(文脈次第)

必要に応じて文脈を教えていただければ、より適切な表現にご提案できます。

「じゅんびを かれ と いってみました」になっているようです😓。 「行ってみる」を「いってみる」と解釈しているので不自然と言っているようにも思えますが、 言い換え方は「おこなう」の意味のようなので、意味が分かっているならば読みの方も 「おこなってみました」にはならないものなのだろうか?とは思ったりも。 ともあれ、読み違いの起こらない文章にするのが手っ取り早いようです。 という訳でAIにしても精度が上がりませんでしたという話でした😅。因みにEdgeの読み上げは正しく読んでくれます😄。

2026/05/01

AM中に起床。

gcc-16.1がリリースされている模様(アナウンス)。 でも、Rustのフロントエンドについては特に記述が見当たらず。

Emacsのgitリポジトリを眺めていたら w32image.cをMinGWビルドでは常に有効にするという 変更が入ったようなのですが、Cygwinのw32ビルドの事を無視した #ifdef 切り替えを行っているようなので、 忘れないうちに対応しておくことにしたり。 WINDOWSNTというdefineで(よく考えずに他は対応されていないので関係無しとして)切り替えようとする 変更が入ったときは注意が必要です。

w32ビルドの Cygwin Emacsで yank-mediaの動作確認を行ってみたのですが、何やらうまく動かなくなっていたり。 クリップボードから画像ファイルへの保存は問題無くできているのですが、 orgモードで貼り付けた画像へのリンクが、いつの間にか 「[[attachment:clipboard-20260501T123947.png][clipboard-20260501T123947.png]]」のように記される ようになったようです。しかし これだと画像を見つけられずインライン表示されません。 以前と同じく「[[attachment:clipboard-20260501T123947.png]]」とすればインライン表示できました。 このリンク文字列の生成って誰がやっているんだっけ?🤔

GoogleAIで「[[fileパス][説明]]」と「[[fileパス]]」とでは意味が違うのだっけというのを聞いてみたら、 意味が違っているらしくて前者の場合はインライン表示できないという回答がありました。 で、標準のリンク挿入では自動的に説明が入るとも回答があったのですが、 少なくとも以前確認したときは説明は付かなかったし ハマった記憶も無いので、ここ最近のorg-modeのアップデートで余計な事をされるようになったと いう感じなのでしょうか? 対応策としては手動で編集する方法の他に、 アドバイスを使うという案が提示されました。

(defun my/org-yank-media-no-description (orig-fun &rest args)
  "yank-mediaで挿入されるリンクから説明文を省くアドバイス"
  (cl-letf (((symbol-function 'org-link-make-string)
             (lambda (link &optional description)
               ;; 説明文(description)を無視してリンクを生成する
               (concat "[[" link "]]"))))
    (apply orig-fun args)))

(advice-add 'org--image-yank-media-handler :around #'my/org-yank-media-no-description)

アドバイスの書き方が未だによくわかっていないので、そのまま適用してみたのですが 所望のとおりに説明文なしのリンク文字列が貼られるようになりました。ほぅ....。 それにしても今のデフォルトの挙動は誰得なんだ?

どうやら Emacs-31 のブランチが来週作成される事になったらしい (The emacs-31 branch will be cut in one week)。 新しいガベージコレクタは31には含まれないようですが、 効果のほどは微妙みたいなので 個人的には含まれなくてもまぁ良いかなと思います。 それよりもWindowsビルドでのカラー絵文字表示対応がやっと公式にリリースされる事の方が大きいです。 2024年10月に対応が入ってから、恐らく31.1がリリースされるのは 早くても今から半年後になると思われるので、約2年間寝かされてる感じになる訳で。 ほんと、このリリースサイクルはなんとかならないのだろうか?と思わなくもありません。

「上伊那ぼたん、酔へる姿は百合の花」のアニメ。ちゃんとは見ていなかったのですが、 先週観たときはこういう作風だったっけ?と思うくらいに絵が荒れてた記憶があったのですが、 今回は普通のアニメの絵だなぁ?と思ったり。違うアニメを見てたのだろうか? と思ったくらいなのですが、検索してみたら先週の3話が特別だったもよう。

2026/04/30

AM中に起床。

先日のファイル内情報検索。gpt-oss:20b のようなGPUに乗るモデルを使えば だいぶ高速に探し出せるようです。今のところはモデルをうまく使い分けるのが良さそうです。

何気に観ていた「氷の城壁」のアニメのシーンで「正反対な君と僕」のキャラクターが背景に出てきたので なんで?と思ったら同じ作者の漫画だというのを知りました (作者:阿賀沢紅茶 のWikipedia)。そうだったのか。物語の方向性は全然違うのですが、言われてみればキャラクターの絵柄が同じ気がしてきました。

明日付けになっていますが、プロ遊の下の 「Emacsでアクセサリを表示してみたくなった」 を更新してみました。きっかけは拙作のmcalendarがちょっとバグっていたのに気づいたからなのですが、 それだけシレっと差し替えておこうと思ったところ他も地味に更新していたり、最近のEmacsだとバイトコンパイルで ワーニングになるのを直したりしていたため、一通り更新版に入れ替えてみました。ご参考まで。

2026/04/29

AM中に起床。

Emacsの doc/emacs/emacs.texi(英文)をplaintextに変換して、 Ollama+qwen3.6:35b に食わせて「マウスで矩形選択する方法について記されていますか?」 と聞いてみたら、そういう記述は無いという返事が返ってきました。 全文が含まれているのに なぜか「このファイルは索引を示している」という事を言っているので、 今度は「このテキストファイルの内容を日本語に翻訳してください。」 とリクエストしたところ、どうやらファイルの最後の方に記された索引部分の途中からが 内容として認識されているらしいのが分かりました。 最初の目次や最後の索引を削っても約47000行(2.2MiB)あるので読み込み切れないか。

それにしても、Emacsでのマウスによる矩形選択方法は Google AIモードで聞いても ズバリ正解は出てきません。以前記した通り、Infoに記されてはいるのですが、 まだ発見されていないという感じなのか、文章の書き方が悪いのかよくわかりません。

マウスによる矩形選択方法の記述が含まれる Infoの14章(英語)だけを切り出して Ollama+qwen3.6:35bに食わせて 「このテキスト文書の中にEmacsでマウスによる矩形選択を行う方法が記されていますか?」 と聞いてみたところ、 「はい、記されています。該当するのはセクション =14.5 Rectangles= の中です。」と 正しく回答が返ってきました。意味は汲み取れているようです。

info全部入りは無理なので、適当なサイズに分割してそれぞれを食わせて検索するのはどうか? と思い試してみたり。以下のようなスクリプトで 分割した info_*.txt ファイルを食わせて 順に問い合わせを行うというものです。

#!/bin/bash

for info in info_*.txt; do
    echo "==== ${info} ===="
    cat ${info} | ollama run qwen3.6:35b --hidethinking "$1"
done

問い合わせ内容は「矩形領域をクリアする方法」にしてみました。かなり時間はかかりますが、一応見つけられました。

$ ./search_info.sh 'Emacsで矩形領域をクリアする方法が記されていればその方法を詳しく教えてください。記載がなければ無いという旨だけを回答願います。'
==== info_01.txt ====
ご提供いただいたGNU Emacsマニュアルの抜粋には、矩形領域をクリアする方法についての記載はございません。

==== info_02.txt ====
提供されたテキストには、矩形領域をクリアする方法についての記載はありません。

==== info_09.txt ====
提供されたテキストには、矩形領域をクリアする方法に関する記載は一切ありません。

==== info_10.txt ====
ご提示いただいたテキストでは、Emacsで矩形領域をクリアする方法に関する記載はございません。

==== info_11.txt ====
ご提示いただいたテキストには、矩形領域をクリアする方法は記載されていません。矩形領域そのものの存在には触れておりますが(`"There is another kind of region: the rectangular region. *Note Rectangles::."`)、その操作やクリア(削除)方法に関する詳細な記載は含まれておりません。

==== info_14.txt ====
記載されています。本文に基づき、矩形領域をクリアする方法を詳しく説明します。

### 矩形領域をクリアする方法
**コマンド:** `C-x r c`
**関数名:** `clear-rectangle`

#### 1. 矩形領域の指定
矩形コマンドは、`point` と `mark` の位置関係によって操作範囲を決定します。クリアしたい範囲を指定するには以下のいずれかを行います:
* **手動指定:** マークを矩形の一方の隅に設定し、ポイントを対角の隅に移動します。
* **Rectangle Mark mode:** `C-x <SPC>` を押してモードを有効にし、マウスや矢印キーで矩形を囲みます。

#### 2. クリアの実行
指定した矩形領域が存在する状態で `C-x r c` を実行すると、**矩形内の既存のテキストがすべて空白(スペース)に置き換えられます**。これにより、テキストは削除されず領域の構造だけが空欄(クリア)されます。

#### 補足(本文の記述に基づく注意点)
矩形領域の消去・空欄化には `C-x r c` の他に `C-x r d`(`delete-rectangle`)がありますが、本文では明確に区別して記載されています:
* `C-x r c`:領域の中身だけを空白にする(`blanks out existing text`)
* `C-x r d`:テキストを完全に削除し、後ろに続くテキストを左に詰める

矩形の枠組みを残して中身のみをクリアしたい場合は、本文の記述通り `C-x r c` をご使用ください。また、この操作はマークがアクティブな状態でないと有効になりません(Transient Mark mode がオフの場合は `C-x <SPC>` で明示的にマークを有効にする必要があります)。

==== info_15.txt ====
提供されたドキュメントには、矩形領域をクリアする方法の記載はありません。矩形に関する記述は「15.3 Saving Rectangles in Registers」において、レジスタへのコピー(`C-x r r`)や貼り付け(`C-x r i`)のみが解説されており、クリア・削除に関する記載はございません。
:
#以下省略

ファイル分割不要で もっと高速に動作すれば、grep のようなノリで意味検索に使えそうには思ったりも。 何より英語文書に対して日本語で意味検索できるというのはやはり画期的に思います。

2026/04/28

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

調べごとをして終了。

2026/04/27

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

調べごとをして終了。

2026/04/26

AM中に起床。

掃除したり。

少し前にスマホのOSアップデートを行ったのですが、それ以降 スケジュール&メモ アプリの アラーム通知が出たり出なかったりして不便になってます。習慣的に使用していないアプリは 閉じているのですが、どうやら閉じているとアラーム通知が出なくて、開いていれば通知が出る という感じにも見えています。
GoogleAI回答の設定確認方法などを頼りにそれらしい設定を弄ってみたのですが、どれも有効に なっているよなぁ?と思ってアプリを再度起動したらいきなりバックグラウンド実行の許可を求める ダイアログが開いたので許可し直してみたところ、閉じても通知が届くようになったり。 でもバイブレーションが動いたり動かなかったりでなんだこれ?って感じ。 そもそも設定を変えていないのだからその通りに動けばよいだけなのですが。訳が分からん。

2026/04/25

AM中に起床。

Edgeがアップデートされているなぁ?とは思ったのですが、音声読み上げが動かなくなっているようだったり。 以前マルチリンガル音声を選ぶと日本語と英語が混ざっていても それなりに読み上げられるという事で設定していたのですが、選択肢にマルチリンガル音声が無くなっているようです。 別の音声を選択してみたのですが、一部の文章は読み上げてくれるものの大部分が読み上げられなくなりました。 入力ミスのチェックに使っていたのですが....🥺
よく探してみるとマルチリンガル音声(Microsoft Ava Multilingual Online(Natural) - English(United States))を 見つけられたのですが、なぜか読み上げられない部分があるのは変わらず。 しかたないのでEdgeを再起動してみたらイケるようになった気も。しばらく様子見。

2026/04/24

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

契機が分からないのですが、OllamaでGPUとCPUの両方を使っていたのですが、 いつのまにかCPUだけしか使わなくなってるなぁ?と思ったり。高頻度でアップデートされるので、 そのうちのどれかと連動しているのかも知れませんがよくわからず。
モデルに依存するか?と思い、GPUメモリに納まる gpt-oss-safeguard:20b を使ってみたところ こちらもGPUを使用しないようだったり。流石になんでだ?とは思ったので Windowsを再起動してみたところGPUを使用するようになりました。 何かを契機にGPUを使わないスイッチが入ったのだろうか?謎。

そういや Copilot Keyboardのアップデートは設定のバージョン情報で確認していたのですが、 今月はまだアップデートが来ないなぁ?と思い検索してみると、 4月23日に正式版になっていたらしい (Windows Blogs)。 ベータからは正式版にアップデートの通知は無いのか?しかたないので、ダウンロードして 上書きでインストール&再起動してみたのですが、キーボード入力がおかしなことになったので、 一旦 Copilot Keyboardをアンインストール&再起動そしてインストールし直しで使えるようになりました。

前回から変わった点や新規追加案件、思ったことをメモっておこうと思います。


Emacs起動時直後のIME切り替えがうまくいかない件が直ったように見えるのと、 文節編集のショートカット(まだちょっと足りていません)が実装されたのは良いと思いますが、 他は基本的に直っていませんでした。 ベータ版だとまだ修正される可能性を期待できたのですが、 正式版でも月一の頻度で修正が出るのか?をアクアに聞いたら(真意のほどはともかく) 「毎月必ずという決まった頻度ではなくなる」と言われました。 MS-IMEでは大丈夫な 単語辞書(Copilot Answer)が表示できないのだけはなんとかならないだろうか? 今のところEmacs(Cygwin/MinGWとも)だけがダメっていうのが辛い🥺。

2026/04/23

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

ノートPCのほうでCygwin3.6.9を入れて、オリジナルのcygwin1.dllでEmacsハングの再現と Emacsの実行バイナリをgdb上で動かすとちょいちょい謎のトラップシグナルを受ける件の再現を確認 してみたり。結果はどちらも直ってはいませんでした(ソースコード的にも関係ありそうな場所に 変更は入っていなかったので、まぁそうなるかなとは思ったりも)。という訳でパッチをあてた cygwin1.dllに差し替えてしばらく様子見。デスクトップPCの方はいきなり差し替えで対応。

以前、いつの間にか郵便ポストがなくなっていたことがありましたが、 いつのまにか新しいのが設置されていることに今日気づきました。 ポストって無くなるものなのかと思っていたのですが、復活することもあるのかと思ったりも。

GIMP 3.2.4がリリースされていたり (リリースアナウンス)。 3.2.2から1か月弱しか経っていませんが 割とたくさんのバグフィックスが行われているようです。

2026/04/22

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

Cygwin 3.6.9-1がリリースされている模様 (リリースアナウンス)。 3.6.8は?と思ったのですが欠番になってるみたい。 Emacsハングに関連しそうな修正は入っていない感じなので、 3.6.7と同じくEmacsハング対応にパッチを当ててビルドして アップデートの準備をしたり。ビルド自体は問題無し。差し替えは明日以降行う予定で。

2026/04/21

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

調べごとをして終了。

2026/04/20

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

調べごとをして終了。

2026/04/19

AM中に起床。

掃除したり。

鬼滅の刃のアニメ再放送。改めて観ると今回の3話目で色々説明されてるなぁと思ったりも。 初見で一回観ただけでは覚えられないくらいの情報が含まれてるように思えます。

たまたまですが、ollamaで使用できる最近のモデルの一覧を眺めてみたら、 qwen-3.6というのが出ているらしいのを知ったり。Webで検索してみるとつい最近出たようで、 画像認識精度が上がっているっぽい感じに思えたので少し試してみたり。 因みに我が家では以前遭遇したIPv6が有効だと ollama pullに失敗したので一時的にIPv6を無効化して pull しました。 さておき、qwen3.5では微妙に数え間違えていた 蝶の標本を見せたら正しい数が返ってきました。 以前テストで作成した「円の数を数えるテスト」 はどうか?と思い「この画像には何個の円が描かれていますか?」とだけ聞いたところ 少し時間がかかって「15個」という回答が返ってきました。 なんとなく左下隅にある小さな円が数え漏れている感じに思いますが、前回の11個よりは だいぶ惜しい感じに思います。

先日の流れで qwen3.6:35bでも SVGで猫の絵をリクエストしてみたら、 以下のようなのが描かれました。

画伯感はありますが、手で弄った個所はありません。先日のGoogleAIの猫の絵を見て思いますに 「猫口」にするだけでだいぶ印象が違うかも知れないなぁ?とは思ったりも。

2026/04/18

AM中に起床。

たまにですが、Emacsのキーボードマクロの中に「M-x hogehoge-long-long-command」のようにキー割り当てを 行っていないコマンドを混ぜて実行したくなる時があります。 このとき、「M-x ho[TAB]」とやるとCompletionバッファが開いて候補が出てきて、 「M-x hogeh[TAB]」くらいで確定しても一応マクロ実行できるのですが、 マクロの記録上は「ESC x ho TAB geh TAB RET ....」というように、「M-x hogehoge-long-long-command」を 実行した感じで記録される訳ではなくキーシーケンスそのまんまになっているようです。
機能するのでまぁいいかとも思ったのですが、キーバインドした方が効率は良いのと、 何度か記録しなおす場合はやっぱり長いコマンドを入力するのは面倒です。 で、ストローク数は多いけど一時的には覚えやすいキーバインド 例えば「ESCキーをN回押し + キー」を使うのはどうか?と思った次第です。 まず前提として例えば「ESC×3回」をプレフィックスとして一時的な割り当てを好きなように 行ってよいという「自分ルール」にします。 例えば、「M-x global-set-key」で「ESC ESC ESC a」に コマンドhogehoge-long-long-commandを割り当てて、 以降はキーボードマクロなどで「ESC ESC ESC a」を使用するという感じです。 もちろん .emacsに設定しても良いと思いますが、どうせ覚えていない事を考えると 設定しなくても良いかな?と思ったりもします。 まぁ、設定しておけば「こんなコマンドだったなぁ?」を「M-x describe-bindings」で調べられる というメリットはあるかも知れません。 因みにdescribe-bindings上では「ESC×3回 a」は「M-ESC M-a」って表示されるようです。 ただし、Windows11では 「ALT+ESC」は アクティブウインドウ切り替え のショートカット みたいなので、文字通り入力してはいけないようです😓

以前、org-modeで svgのコードブロックをレンダリング できないのだろうか?と思ったのですが、ob-svgなんてものは無いのでできないという事で放置してました。 何気に思い出して GoogleAIにエラーする旨を告げたところ srcブロックに「:tangle file名」というパラメータを 付けると、「C-c C-v t」で指定したファイル名でコードブロックがそのまま保存されるので、 [[file:file名]]でリンクを記して「C-c C-x C-v」で表示すれば良いという別の方法が出てきました。 「ちょろっと確認してみたい」という要件を満たしているようには思ったりも。

SVGプリビュー on Emacs org-mode

何気にGoogleAIで「SVGで富士山の絵を描いて」とリクエストしてみたら描かれたのですが、 桜の枝を足せますとか、夜桜風にできますとか、花びらをアニメーションで散らせますとか、 水面に逆さ富士をあしらえるとか、星を瞬かせることができるとか 言ってきたので、マジで?と思い全部入りでお願いしたら次のようになりました。


おぉ....😮 水面もなんか動いとる...

調べてみたら、今年の2月にリリースされた「Gemini 3.1 Pro」では SVGの描画能力が大幅に向上しているらしい。「AIモード」がどういうモデルを使用しているのかは分かりませんが、 「アニメーションできます」と言ってきた所を鑑みますに、Gemini 3.1 Proと何かしら関係があるのかも? さておき、画伯感が無くなるのは時間の問題かもしれません😅。

2026/04/17

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

調べごとをして終了。

2026/04/16

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

調べごとをして終了。

2026/04/15

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

org-modeでは簡単な表を書くことができて HTMLに良しなに変換ができます。 これとは別にtable.elという標準のELISPのコマンドを使えばASCII文字で表を 編集してこちらもHTMLに良しなに変換ができます。 後者はほとんど使ったことが無かったのですが、結合したセルを扱えたり セルの中で折り返すように編集したりすることができるようです。

「M-x table-recognize」で表のようだったら良しなにふるまうモードにして編集。 因みに以下は絵文字を含んだ行に空白が余計に入っているように見えますが、 Emacs上の表示はズレていないので、Edgeのpreタグのレンダリングの問題に思ったりも。

+----------+----------+----------+------------------------+---------------------+
|見出し1   |見出し2   |見出し3   |見出し4                 |見出し5              |
+----------+----------+----------+------------------------+---------------------+
|          |          | 結合したセルで長い文章を入れた場合も良しなに編集可能    |
|          |          |                                                         |
+----------+----------+----------+------------------------+---------------------+
|          |長い文章が|          |長い文章を入力しても枠の| 🥺🤔😄              |
|          |記されたセ|          |中に納まるように折り返す|                     |
|          |ル        |          |ので不要に横長にならない|                     |
+----------+----------+----------+------------------------+---------------------+

リージョン選択して「M-x org-export-region-to-html」でHTMLに置き換えられた結果は 以下のような感じ。

見出し1    見出し2    見出し3    見出し4                  見出し5              
          
          
          
          
 結合したセルで長い文章を入れた場合も良しなに編集可能    
                                                         
          
          
          
長い文章が
記されたセ
ル        
          
          
          
長い文章を入力しても枠の
中に納まるように折り返す
ので不要に横長にならない
 🥺🤔😄              
                     
                     

ほう.....

2026/04/14

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

世界量子デー。去年は何それ?って感じでしたが、 今年は少し検索してみると関連した記事やポストなどがあるように思ったりも。 英語のWikipediaページ は存在しますが、日本語のページが無いのは1年前と変わらず。

そういえば REALFORCE TYPING CHAMPIONSHIP って今年は開催されないのかしら?

2026/04/13

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

調べごとをして終了。

2026/04/12

AM中に起床。

掃除したり。

そういえば、三省堂の建て替え工事が行われていて、今年の春ごろ完成予定だったな (以前のメモ)と思い調べてみたら、 3月19日にリニューアルオープンしていたらしい (アナウンス)。 そのうち行ってみたいです。

2026/04/11

AM中に起床。

散髪にお出かけ。それにしても今日は暑かった。

Markdownの事を調べていたら、表示レイアウトの細かな話になると「HTMLで記す」みたいになってるなぁ と思ったりも。先日知った文字列を回転させるとか、 数式をレンダリングするとか、 \[ x={\frac {-b\pm {\sqrt {b^{2}-4ac}}}{2a}} \] 他にも、 テキストに図形を重ねたり とか、自由度高いなぁ と思います。手間はともかく、いつの間にかHTMLで書けるようになっていると思ったりも。

2026/04/10

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

調べごとをして終了。

2026/04/09

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

以前、LLMでもSVG形式ならば画像生成できるというのを知りましたが、 色々なお題やモデルで描かせた結果が置いてある 「LLM SVG Generation Benchmark」 というサイトの存在を知ったり。画像生成AIのに比べれば画伯感があるのは否めませんが、 中には割とイケてる感じのものもあるようです。ただ、お題が無茶ぶりな感じがしなくもありません。

BIOSアップデートが来ていたり。やっぱり月一回の頻度だなぁ(前回)。

調べごと。

2026/04/08

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

調べごとをして終了。

2026/04/07

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

本物お仕事で EmacsのTRAMPをよく使うのですが、以下のようなネットワーク接続の場合に、 思った感じにならないなぁというのに気づきました。

      +-----------+          +-----------+          +-----------+
      | HOST-A    |          | HOST-B1   |          | HOST-C1   |
  ----|  x.x.x.x  |----+-----|  x.x.x.X  |----------|192.168.x.x|
      |           |    |     |           |          |           |
      +-----------+    |     +-----------+          +-----------+
                       |
                       |     +-----------+          +-----------+
                       |     | HOST-B2   |          | HOST-C2   |
                       +-----|  x.x.x.Y  |----------|192.168.x.x|
                             |           |          |           |
                             +-----------+          +-----------+

HOST-C1とHOST-C2に到達するまでの経路は違うのですが IPアドレスは同じという系です。 ここで、HOST-C1のディレクトリを「/plink:userA@x.x.x.x|ssh:userB1@x.x.x.X|ssh:userC1@192.168.x.x:/pathto/..」 で開いた後、HOST-C2のディレクトリを「/plink:userA@x.x.x.x|ssh:userB2@x.x.x.Y|ssh:userC2@192.168.x.x:/pathto/..」 開こうとしたのですが、なぜかHOST-C1の方が開いてしまいました。どうやらHOST-C1とHOST-C2のIPアドレスが同じ為か 途中の経路が違っていてもそれを区別できていないようです。えぇ....?🥺

んー、でもよく考えてみたら、

      +-----------+          +-----------+          +-----------+
      | HOST-A    |          | HOST-B1   |          | HOST-C    |
  ----|  x.x.x.x  |----+-----|  x.x.x.X  |-----+----|192.168.x.x|
      |           |    |     |           |     |    |           |
      +-----------+    |     +-----------+     |    +-----------+
                       |                       |
                       |     +-----------+     |
                       |     | HOST-B2   |     |
                       +-----|  x.x.x.Y  |-----+
                             |           |
                             +-----------+

とは区別が付かないかもなぁ?とは思ったりも。ルートが違う事と到達点が違う事とは無関係なので どうしようもないかもなぁ?と思いなおしたりも。

ふと、HTMLで文字を回転させることってできるんだろうか?と思い、検索してみたらGoogleAI回答に CSSのtransform:rotate(角度deg);プロパティを使用すれば可能と記されていて、例示されたコードを 貼り付けてみたら

「回転する文字」

ホンマや....と思ったり。

2026/04/06

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

Revision2026の Prizegiving をちょっとだけ観られたり。

以前、タスクマネージャで見たときのGPUの3D負荷が常時30% くらいあるというのに気づきました。その後もそういう感じだったのと、それとは別にGDIアプリによっては 起動しているとEmacsと同じように負荷がかかる事象を確認していました。 で、ふとここ数日なぜがGPUの負荷が下がっているようだったのでなんで?と思って調べてみたところ、 どうやら Ollamaの新しいバージョンが起動しているとGPUの周波数が高いままになっているのが影響しているようでした。


というメカニズムだったようです。タスクマネージャではGPUの周波数までは分かりません。 この状態でGPUの使用量だけで見ると、GPUに負荷をかけているつもりはないのになぜか使用率が高いという 直感とは反する値が表示されているように見えるという事のようです。

2026/04/05

AM中に起床。

掃除したり洗濯したり。

node.jsでCLIのプログラムって作れるよね?と思い、qwen3.5:35bにひな形作成をリクエストしたら 一応出てきたのですが、それがどうにも動かなかったり。修正を nemotron-cascade-2:30bにリクエスト してみたら、古い書き方だというような事を言っているのですが、出てきたコードがこれもやっぱり動かなかったり。 どういうこと?🤔
GoogleAIに修正をリクエストしてみたところ、nemotron-cascade-2:30bの文法も古いとか間違っている点が指摘されて、 順に直していくと最終的に動くようになりました。てか、JavaScriptってそんなに色々変わってるの?

Revision 2026。「Modern Graphics」からですが観られたり。「Cooler Master 3D Printing Compo」 というコンポを観たり。 どうやら Cooler Master の PCケース(参考)向けに 自作のアクセサリを競うというものらしい。今回のコンポでは割と実用的なものが多くて奇抜なものは 無かったように思うのですが、こういうのもコンポになるんだとは思ったりも。 その後もいくつかのコンポを観られましたが、デモコンポはタイムスケジュール的に無理だなぁ。まぁ毎度のことですが。

Emacsのmasterブランチにorg-modeの9.8.1が入った模様。9.7系から9.8系になるのですが、 キーバインドが変わったりしているので、Emacs30.xから31系への移行でトラブルが発生する可能性は あるかも知れません。因みにorg-modeのmainブランチは9.8-preから10.0-preというバージョンに変わってました。 9.9は?とは思いましたが、メジャーバージョンが変わっているので、今後大きな機能変更が加えられていく可能性が あるのかもしれません。

2026/04/04

AM中に起床。

copilot.elというか GitHub Copilotとの連携の仕組み。 copilot.elのログレベルを変えてJSON-RPCのやりとりを観察したり AIに聞いたりしながら仕組みがなんとなく分かったような気も。 とはいえ、プライベート環境ではこれ以上調べられないので続きはまた別途。

そういやvimも GitHub Copilot連携できるんだよな?(こちらはGitHub社が開発しているらしいですが)と思ったり。 同じような事をやってんじゃね?(正確にはvimでやっていることをEmacsに輸入しているようですが)と思い copilot.vim リポジトリをcloneして眺めてみたのですが、 vimスクリプトよくわからんという状況。

copilot-language-serverってオープンソースじゃないのか。あと、LSPサーバーになるようなのですが、 プロトコル上で指定されるファイルパスがWindowsネイティブパスになりそうな予感がします。 以前、D言語向けのLSPサーバを試してみたときにCygwin対応をやったなぁ? というのを思い出したのですが、同じような対応をしないとダメな予感がしてきました。

GitHub Copilot Chatは、gptelでも対応してるっぽい。copilot.elの中にcopilot-chatというのが含まれている ようですが、これとは別に copilot-chat.elというパッケージも存在していて、 copilot.elのチャット機能と copilot-chat.elを混在して使用することはできないらしい。 そして、GitHub Copilot Chatと Microsoft365 Copilot Chatは別物で、先日述べた通りcopilotという文字列が 濫用されすぎてて区別がつきません...🥺

Revision 2026。ライブストリームが全然再生できなかったり。「TECHNICAL DIFFICULTIES」という画像が 表示されたので、何かしらトラブっているのだろうと思われます。しょんぼり🥺

2026/04/03

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

訳あって Emacsから GitHub Copilotが使えるのか調べたり。 Emacsのクライアントとして「copilot.el」が 存在するのは薄っすら知ってはいたのですが、どういう仕組みで動くものなのかは知りませんでした。 copilot.elとは別にnode.jsで動作する @github/copilot-language-serverも 必要なのですが、幸い先日vivliostyleを試すのにインストールしたのでどうにかなるだろうと思ったり。 で、Cygwinの emacs-w32だと ファイルパス表現が Windowsネイティブで動作するnode.jsと相性が悪いため、 「M-x copilot-install-server」コマンドでインストールすると Cygwinのパスとは合わないところに インストールされてしまいます。ひとまずコマンドとして使えればよいのだろうという事で、 copilot-language-serverは手動インストールで対応してみました。で、copilot-loginを実行してみるのですが、 w3mが起動されて思った操作ができなかったので、GoogleChromeをブラウザ起動するように 変数browse-url-browser-functionやらbrowse-url-chrome-programを設定。 外部ブラウザを起動してサインインでワンタイムコードを入れるとなんとなく大丈夫っぽいのですが、 Emacs側のverifyでタイムアウトエラー。どこで突っかかっているのかよくわからず。 ただ、JSON-RPCというプロトコルで通信しているようなので、ファイルパスの問題とかでは無いだろうとは思ったりも。
それにしても、「copilot」の文字列には色々なものがかかっていて、どのcopilotの事を言っているのか混乱します。 GitHub CopilotにアクセスするCLIツールも copilotっていうコマンド名のようで なにがなんだか🥺

2026/04/02

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

調べごとをして終了。

2026/04/01

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

覚書。今週末はメガデモイベントの Revision 2026 開催。


TOP

古いの
2026.03 2026.02 2026.01
2025.12 2025.11 2025.10 2025.09 2025.08 2025.07 2025.06 2025.05 2025.04 2025.03 2025.02 2025.01
2024.12 2024.11 2024.10 2024.09 2024.08 2024.07 2024.06 2024.05 2024.04 2024.03 2024.02 2024.01
2023.12 2023.11 2023.10 2023.09 2023.08 2023.07 2023.06 2023.05 2023.04 2023.03 2023.02 2023.01
2022.12 2022.11 2022.10 2022.09 2022.08 2022.07 2022.06 2022.05 2022.04 2022.03 2022.02 2022.01
2021.12 2021.11 2021.10 2021.09 2021.08 2021.07 2021.06 2021.05 2021.04 2021.03 2021.02 2021.01
2020.12 2020.11 2020.10 2020.09 2020.08 2020.07 2020.06 2020.05 2020.04 2020.03 2020.02 2020.01
2019.12 2019.11 2019.10 2019.09 2019.08 2019.07 2019.06 2019.05 2019.04 2019.03 2019.02 2019.01
2018.12 2018.11 2018.10 2018.09 2018.08 2018.07 2018.06 2018.05 2018.04 2018.03 2018.02 2018.01
2017.12 2017.11 2017.10 2017.09 2017.08 2017.07 2017.06 2017.05 2017.04 2017.03 2017.02 2017.01
2016.12 2016.11 2016.10 2016.09 2016.08 2016.07 2016.06 2016.05 2016.04 2016.03 2016.02 2016.01
2015.12 2015.11 2015.10 2015.09 2015.08 2015.07 2015.06 2015.05 2015.04 2015.03 2015.02 2015.01
2014.12 2014.11 2014.10 2014.09 2014.08 2014.07 2014.06 2014.05 2014.04 2014.03 2014.02 2014.01
2013.12 2013.11 2013.10 2013.09 2013.08 2013.07 2013.06 2013.05 2013.04 2013.03 2013.02 2013.01
2012.12 2012.11 2012.10 2012.09 2012.08 2012.07 2012.06 2012.05 2012.04 2012.03 2012.02 2012.01
2011.12 2011.11 2011.10 2011.09 2011.08 2011.07 2011.06 2011.05 2011.04 2011.03 2011.02 2011.01
2010.12 2010.11 2010.10 2010.09 2010.08 2010.07 2010.06 2010.05 2010.04 2010.03 2010.02 2010.01
2009.12 2009.11 2009.10 2009.09 2009.08 2009.07 2009.06 2009.05 2009.04 2009.03 2009.02 2009.01
2008.12 2008.11 2008.10 2008.09 2008.08 2008.07 2008.06 2008.05 2008.04 2008.03 2008.02 2008.01
2007.12 2007.11 2007.10 2007.09 2007.08 2007.07 2007.06 2007.05 2007.04 2007.03 2007.02 2007.01
2006.12 2006.11 2006.10 2006.09 2006.08 2006.07 2006.06 2006.05 2006.04 2006.03 2006.02 2006.01
2005.12 2005.11 2005.10 2005.09 2005.08 2005.07 2005.06 2005.05 2005.04 2005.03 2005.02 2005.01
2004.12 2004.11 2004.10 2004.09 2004.08 2004.07 2004.06 2004.05 2004.04 2004.03 2004.02 2004.01
2003.12 2003.11 2003.10 2003.09 2003.08 2003.07 2003.06 2003.05 2003.04 2003.03 2003.02 2003.01
2002.12 2002.11 2002.10 2002.09 2002.08 2002.07 2002.06 2002.05 2002.04 2002.03 2002.02 2002.01
2001.12 2001.11 2001.10 2001.09 2001.08 2001.07 2001.06 2001.05 2001.04 2001.03 2001.02 2001.01
2000.12 2000.11 2000.10 2000.09 2000.08 2000.07 2000.06 2000.05 2000.04 2000.03