昔の最近の出来事(2026.01)

2026/01/31

AM中に起床。

お出かけ。今日は見るだけ....ちょっと触るだけ....在庫あるな....期間限定特価だな....買うか。 と言うわけで、唐突にラピッドトリガーのキーボードを買ってしまいました😅。 買ったのはLogicoolの「G515 RAPID TKL の白」です。 ロープロファイルでテンキーレスで日本語配列でリニアという事で、 現在使用しているサンワサプライのロープロファイルでテンキーレスの日本語配列で赤軸 (以前の日記)から乗り換えられるかも? と思ったところでした。今気づいたのですが、サンワサプライのはもうすぐ丸8年使っていることになるのか。 やはりメカニカルキーボードは耐用年数が長いようです。 さておきLogicoolの方。まずはキーの設定とかは行わずデフォルトで使ってみたのですが、 赤軸よりもリニア感が高いように感じました。 これまでのキーボードにも何かしら慣れている所があって、感触の違いはありますが違和感は 特に無いように思いました。しばらく使って指を慣らしてみたいと思います。

そういや、Windows11ではデバイスの照明制御を行えるようになっているらしい。 「Logicool G HUB」というロジクール製品のデバイス設定を一括管理するアプリで照明設定にある 「WINDOWS設定」というスイッチを有効にするとWindowsの「個人用設定→動的ライティング」で 照明設定を行えるようです。一通り眺めてみたのですが、結局 G HUB 側の設定を採用してみたり。 また気まぐれで変えたりするかもしれませんが😅。

ラピッドトリガー設定を行ってみたり。ラピッドトリガーはデフォルトは無効になっているので、 意図的に有効に設定する必要があるようです。アクチュエーションポイントとは別に設定可能っぽい。 ちょっとだけ弄ってみたのですが、タイピングしている範囲内ではあまり効果の分かる場面は無い気もします。 ローマ字で「ん」を「nn」で入力する場合や促音(っ)を含むような入力の場合にキーを連打することがありますが、 そのような場面で反応が良い気もするようなそうでもないような?みたいな感じです。 ラピッドトリガーの無いキーボードを使ったときに入力ミスが多くなるようだと、 いつの間にかラピッドトリガーの恩恵を受けていたというのに気づく感じなのかもしれません。

2026/01/30

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

以前、EmacsでIMEを切り替えるのに「半角/全角キー」を 使うとかなり高い確率で切り替えに失敗するのを調べたのですが、いまいち原因がつかめず放置していました。 再び気になってきたので調べてみたところ原因が判明。
「半角/全角キー」はMS-IMEに食われているのでキー入力として直接Emacs側でキーが押された事を 知る術がありません。「半角/全角キー」が押されることでIMM関連メッセージが送られてくるので、 そのメッセージを受け取ったらさらに[kanji]というキーが押されたとしてキーイベントを間接的に Emacs本体に伝えるという仕組みです。この為、[kanji]キーが押されてからIMの処理をするのでは無く、 既にIMの処理が終わった後に[kanji]キーが押された事になるので、[kanji]キーが押された事を受けて IMEの状態をトグルしてしまうと、結果的に二度IMの状態をトグルしてしまい 結局切り替わっていない という事が起こっていました。という訳で、[kanji]キーは押された事を受けてEmacs上のIMの状態表示だけを 更新するような使い方をする必要がありました。という訳でキーバインドの設定を直してみたり。 今のところ良好に「半角/全角キー」でも良好に切り替えができるようになりました。しばらくテストしてみよう。
因みに「C-\」などによるIMの切り替えはEmacs本体が主体となってIMMの制御を行っているので 二度トグルするといった事は起こりません。

2026/01/29

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

今更ですが、並列(Parallelism)と並行(Concurrency)の使い分け。 どちらも「同時実行」のニュアンスで使うことはありましたが、厳密に使い分けることは意識していませんでした。 並列はある瞬間も同時に動いていて、並行は時分割なのである瞬間で見ると一つだけ動いているという違いがあるそうな。 一人であっちやったりこっちやったりは並行、複数人で分担してやるのは並列なので、 「一人で並列処理」は厳密には用法間違いという感じなのかも。

以前、ssh接続している状態で「~.」と入力すると接続切断される というのを知ったのですが、「~?」でヘルプが出せるというのを知りました。

$ ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

ssh接続していても、サスペンドすることが可能だったらしい。ほぅ...。

2026/01/28

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

調べごとをして終了。

2026/01/27

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

調べごとをして終了。

2026/01/26

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

気づいていませんでしたが、GIMPの3.0.8がリリースされていた模様 (GIMP 3.0.8 Released)。 次は3.2になるかも知れないらしい。

2026/01/25

AM中に起床。

掃除したり洗濯したり。

Copilot Keyboardのメモ。多分忘れるので、CygwinでIMEパッチ入りのemacs-w32で調べた時の 事象をメモっておくことにします。


バージョンアップで問題なくなれば良いのですが、まだ当面の間は常用に耐えないなぁ...と思います。

全然関係ない流れでキーボードのスイッチに「磁気スイッチ」という方式のスイッチがあるのを知ったり。 以前、ラピッドトリガーなる方式のON/OFF検出方式があるのを 知ったのですが、光学センサーや静電容量でやっているらしい以上のことまでは調べていませんでした。 磁気スイッチは方式の一つという事みたいです。磁気の場合、接点が無いらしい(光学もそうかもですが)ので 軽い荷重にできたりするようです。磁気センサーの性能とかにもよるかもしれませんが、 小型化もできそうな予感がします。

2026/01/24

AM中に起床。

Webを散策していたら、以前知った「Copilot Keyboard」に アップデートが来ているらしいのを知り、確認してみたら確かにアップデートがあります的な ボタンが表示されていたのでアップデートしてみたり(1.0.0.2651というバージョン)。 Windowsの再起動が必要だったのが面倒臭いのでなんとかして欲しいとは思いました。 さておき、Emacsで長い文章を入力するとスローダウンするという現象が確認されているのですが (以前のメモ)改善される感じは特に無し。 ユーザ辞書が使えるようになっていたりするらしいのですが、普段使っていないのであまり関係も無し。 エディタ機能の方は変わらず打ち間違いの修正はまだできない感じです。 誤変換のまま覚えてしまった変換候補を削除することもできません。 また、Emacs上で使ってみると「Ctrl + Space」が何かしら食われているようでマークが使えなくてダメでした。 前は無かった、設定→ショートカットでは 「Ctrl + Space」を「なし」にしているのですがなんでだ?🤔 月に一回くらいのペースでアップデートが来る予定っぽいので定期的に様子見する感じでしょうか。

スローダウンする件。原因は「WM_IME_NOTIFY(0x0282)」のwParam「0xf」が大量に送られてくるから ということが分っています。で、「このメッセージを全部捨ててみたらどうなるか?」と思い、そういう コードにしてみました。するとスローダウンがかなり軽減されることがわかりました。また、ちょっと使っ てみた範囲では副作用(例えば描画が変になったり何かが操作できなくなったり)は無さそうでした。 良し悪しはいったん置いといて、MS-IMEと操作互換が取れているレベルになれば、変換精度の比較も できるかなぁ?とは思ったりも。

英数半角文字混じりの変換。以前 「ESCキー」と「半角/全角キー」を入れ替えていたのをやめてしばらく経ちました。 押し間違いはほぼなくなっているのですが、やっぱり半角英数を入力するときにはIMEを意図的に OFFにしがちです。ただし、全部大文字(MS-IMEとか)大文字始まり(Dockerfileとか)みたいなのは IMEをONにしたまま入力するときはあります。圧倒的に少ないですけど😓。 で、思ったのですが、小文字の場合もいったん大文字始まりで入力しておいて、変換時にすべて 小文字に変換するのはどうか?ということを思ったり。で、実際に試してみるのですが、 例えば「configureとmakeを使ってbuildします」の場合、SHIFTキー単押しを使えば 変換前の「ConfigureとMakeをつかってBuildします」は続けて入力できます。ここで変換をすると 一旦「ConfigureとMakeを使ってBuildします」にはなるかと思います。この状態で ConfigureやMakeやBuildを文節変換することになるのですが ここが一番の問題に思いました。 キー操作が分らない的な話は一旦おいといて、 変換候補が「Configure」「CONFIGURE」「configure」「CONFIGURE」 「configure」みたいな順になっていて、半角の変換候補が驚くほど下に追いやられています。 一度「configure」を選択すれば上の方に上がっては来るのですが、辞書を鍛える必要はあります。 また丸カッコや数字を含む場合も全角の方が優先される感じになっているので続けて入力するならば 意図的に「半角/全角キー」で切り替える方が結局修正の手間が無いので早いという結論になってしまう かもという感じです。英数や記号を含む場合、半角を優先するような重みづけスイッチがあれば 大分様子は変わるかもしれません。実際にどうなるかはわかりませんけど。

Emacs31系になる予定のmasterブランチの doc/NEWSの中に 「** Emacs on MS-Windows now supports color fonts.」という項目があります。 描画やサポートを示す変数や関数が使えるようなことが書いてあるのですが、 実際に変数の内容を表示しようとするとそんなシンボルは無いというエラーになったり。 なんでだ?🤔

2026/01/23

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

調べごとをして終了。

2026/01/22

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

昨日のカレンダー作成で間違えたカレンダーを作成するのはどういう事だ?と思い、 「AIはプログラム的に解決できるような問題にどのように対応しているのですか?例えば「1+2+3はいくつ?」という質問にはどのように答えているのでしょうか?」 と聞いてみました。モデルによって答えにバラつきはあるようですが、 概ね「単純な計算は統計的な結果から答えを導き出していて計算はしていない」、 「計算が必要と判断するような場合は function callingというツール呼び出しで答えを得る」 という事のようです。ローカルLLMの場合は後者は手段/道具を与えていないと思うので、 仮にカレンダープログラムをその場で作って実行すれば正しい答えが比較的すぐに得られるとしても、 それは手段/道具を与えられていないので無理、という事になるのかなとは思います。 回答に「「大きい数や複雑な式(指数、階乗、分数の約分など)は、学習データに少ないため誤答が増えることがあります。」 という文言も含まれていたのですが、そういうことなのねと納得できたりも。 逆に「複雑な問題は道具を使って解決する」仕組みがあるのかと思ったのと、 道具を与えられたとすれば、「データが大きいな....しゃーない、スクリプトでも書くか...」 というような事をするって感じみたいです。ほぅ....。

2026/01/21

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

gpt-oss-safeguard:120bに「2028年のカレンダーを作成してください」と指示してみたら、 結構な時間をかけて微妙に間違ったカレンダーが作成されました。 もっとサクッと(正しいものが)生成されると想定していたので意外に思ったり。 gpt-oss-safeguard:20bだと早く返っては来るのですが、大分壊れたカレンダーが生成されるようです。 因みに、GoogleのAIモードで同じ事を聞いてみたら、祝日の一覧は表示されたのですが、 カレンダー自体は生成されず、そういうツールやサイトを使うのが良い という感じの回答でした。

「2028年のカレンダーを作成する方法を教えてください」に変えてみたら色々な方法が出てきました。 しかし、ELISPのコードとかも出てきたのですが存在しない関数を呼び出すコードになっていて動かず。 結局 Emacsの「M-x calenar」と「calコマンドを使う」方法以外はダメそうな感じでした😓

2026/01/20

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

調べごとをして終了。

2026/01/19

本日休業。AMは通院。

パッチ無しのEmacs31のimage-diredで外部コンバータを使って表示可能な画像が表示できなくなっているようだったり。 29系で image-modeを使用して表示するようになっていたのですが (以前のメモ)、image-dired-image-display なるモード で開くようになっていて、image-modeでは表示可能なものが表示できなくなってっぽい。 image-dired.elにバッファが再利用されないのを改善するパッチをあてているのですが、 パッチをあてればこれまで通り表示可能なので まぁいいかと思ったりも。

2026/01/18

AM中に起床。

掃除したり洗濯したり。

Emacsの31系になる予定のmainブランチをcloneしてパッチ無しの動きを確認できるようにビルドしたり。 ビルド自体は問題無くできたのですが、拙作のsysmonのテキストモードが動かなくなっているなぁ? というのに気づいて調べたり。どうやら aset関数にマルチバイト文字を指定することができなくなっている模様。 グラフィックスアレイの座標位置にピクセルをセットする感覚で、テキストアレイの文字座標位置の文字を asetで書き換えるような使い方をしていたのですがダメになったらしい。仕方ないので substringやらconcatやらを使って切ったり貼ったりする方式に書き換え。釈然とはしていない🙁。

2026/01/17

AM中に起床。

何気にJXL画像をEmacsで表示しようとしたら表示できなくなっていたり。 Cygwinの ImageMagickではJXLフォーマットはサポートされていないので 拙作のperlスクリプトで ラップして見かけ上 JXLフォーマットの読み込みをサポートしている風にしているのですが、 なぜかうまく動かなくなっていたので調べてみたり。 どうやら「magick convert ...」と実行すると 「WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert"」 というメッセージが出るようになっているのですが、このメッセージが出ることが悪さをしているようだったので、 「magick」だけにしてみたところ、コマンドラインではうまく動くようになったのですが、 やっぱりEmacs上では表示がうまくできなかったり。なんでだ?🤔

どうやら「magick convert」と「magick」とではコマンド解釈や処理に互換性が無くなっている部分があるようです。


という訳で、BMPファイルの方はどうにかして修復する方法を調べたり。 ダメなのは RLE圧縮されているBMPで、8bit,4bit パレットのバリエーションがあります。 ImageMagickで修復を試したのですがどうにもうまくゆかず。 結局GIMPを使って RLE圧縮前のファイルを読み込ませてRLE圧縮指定で名前を付けてエクスポートし直すと パレットが壊れる(例えば4bitだったのが8bitになってしまうとか)ような事は無く修復されて エクスポートされているようだったので、これで良しとしてみました。

-auto-orient の位置の方にも一つ問題があります。そもそも -auto-orient を使用する理由は、 以前 TGAフォーマットの画像を表示したとき、 上下が逆に表示されるものがあったからでした。TGAには格納方向フラグというものがあって、 このフラグを考慮しないと上下が思った方向に表示されない場合があります。 Emacsの組み込みImageMagickではMagickAutoOrientImage()という関数を使用していて、 どっち格納かによらず所望の方向で表示されるのですが、外部convertの場合は明示的に -auto-orientを指定する必要がありました。 で、このオプションをどうやって追加するか?という事なのですが、 lisp/image/image-converter.el内でdefvar定義されている変数image-converter--convertersを、 「(imagemagick :command ("wrapped_convert" "-auto-orient") :probe ("-list" "format"))」 というように書き換えていました。しかし、今回の非互換に対応しようとすると、 入力ファイル指定の後に オプションを指定しなければならないのですが、 そういうオプション指定体系に対応していないという問題があります。 とはいえ、image-modeで表示しようとすると 外部コンバータを使用するように指定したファイルが 全てコマンドラインエラーで表示できなくなる為、-auto-orient指定を外すことにしました🥺。
個人的に「command [options] [files....]」となっていないのが筋が悪いと言いますか。 ただ、ImageMagickの場合はオプションの体で処理の順番を明示している所もあるので 正直面倒臭いです。「magick convert」が非推奨なのもよくわからないなぁと思う所もあります。

-auto-orientの影響を確認してみたのですが、外してもデフォルトで-auto-orientが有効な感じに なっているようです。ならば問題になる事は無いかも? だた、現在開発中のmasterブランチ(Emacs31系)では「("convert" "-layers" "merge")」 としているようなので、もしmagickコマンドだけになると動かなくなります。

2026/01/16

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

そういえばと思い、gptelを使って次のようなことをさせてみたり。
以下のようなテキストがあったとして、

 | 1 |  1.2.3.4 , 100.101.102.103 |
 | 2 |  1.2.3.4 , 100.101.102.103 |
 | 3 |  100.101.102.103 , 1.2.3.4 |
 | 4 |  1.2.3.4 , 100.101.102.103 |
 | 5 |  100.101.102.103 , 1.2.3.4 |
 | 6 |  1.2.3.4 , 100.101.102.103 |
 | 7 |  1.2.3.4 , 100.101.102.103 |
 | 8 |  1.2.3.4 , 100.101.102.103 |
 | 9 |  100.101.102.103 , 1.2.3.4 |

gptel-rewriteで 「Rewrite: 文字列「1.2.3.4」を「100.101.102.103」に、「100.101.102.103」を「1.2.3.4」に入れ替えるように置換してください」 という指示で置換を行わせてみたところ、

| 1 | 100.101.102.103 , 1.2.3.4 |
| 2 | 100.101.102.103 , 1.2.3.4 |
| 3 | 1.2.3.4 , 100.101.102.103 |
| 4 | 100.101.102.103 , 1.2.3.4 |
| 5 | 1.2.3.4 , 100.101.102.103 |
| 6 | 100.101.102.103 , 1.2.3.4 |
| 7 | 100.101.102.103 , 1.2.3.4 |
| 8 | 100.101.102.103 , 1.2.3.4 |
| 9 | 1.2.3.4 , 100.101.102.103 |

のように書き換えられました。行頭の空白が無くなっているなど、細かなところで 「その書き換えはしなくてよい」という所はありますが、この程度であれば期待通りに書き換えられるようです。 このような「入れ替え」の置換を普通にやると、一時的に存在しない文字列に置き換えてから2回置換を 実行する(正味3回置換)必要があるかと思います。 ただ、今のところ意外と時間がかかります😅。100倍くらい速くなれば「AI置換」みたいな 編集コマンドとして使えるようになるかも知れません。 EmacsならELISPでそういうのを書けば良いのかも知れませんが(身も蓋もなし)。

もしやと思い、GoogleのAIモードで 「Emacsで文字列Aと文字列Bを入れ替えるような置換を行うことはできますか?」 と聞いてみたら、
はい、Emacsでは正規表現置換(query-replace-regexp)とLisp式を組み合わせることで、
文字列Aと文字列Bを一度に入れ替えることが可能です。

以下の手順で操作します:

1.C-M-% (または M-x query-replace-regexp)を入力します。
2.置換対象(Query replace regexp)に次のように入力し、Enter を押します。
  \(文字列A\)\|\(文字列B\)
3.置換後(with)に次のように入力し、Enter を押します。
  \,(if \1 "文字列B" "文字列A")
  ※ \, は後に続くLisp式を評価することを意味します。この式は「もし1番目のグループ
    (文字列A)にマッチしたら文字列Bに、そうでなければ文字列Aに置き換える」という
    処理を行います。
4.あとは通常の置換と同様に、y(置換する)や !(すべて置換する)で進めます。

という回答が返ってきて、やってみたら所望の通りに入れ替え置換ができました。マジっすか😮 置換対象を正規表現で指定するのはともかく、どのような文字列に置換するかにLISP式が書けるって 応用範囲が広すぎです。そんな訳で「それ、できるよ」ってことでした。

2026/01/15

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

BIOSアップデートが来ていたので入れたり。念のためUSB-typeCは本体から外しておいた為か今回も失敗はせず。

2026/01/14

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

Emacsのハング確認。パッチをあてたCygwin3.6.6で丸4日ほど Emacsのimage-dired+スライドショーで 負荷確認をしていましたが期待通りハングせず。WindowsUpdateのため一旦終了。

WindowsUpdate後に Winボタンからアプリを探そうとしたら変なカテゴライズをされていて これまでの縦に全部表示されるメニューが無くなっているようだったり。 表示方法は切り替えられるようですが、自分で分類できないカテゴリ表示なんて誰が使うの?

2026/01/13

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

先日のorg-modeで表をHTMLエクスポートしない記述方法を含んで 「Emacs Org-mode の覚え書き」 を更新してみました。御参考まで。

2026/01/12

AM中に起床。

そういえば、org-modeで 表を元にして gnuplotや Rを使ってグラフ画像を描くことができますが、 HTMLなどにエクスポートする際にはグラフ画像だけをエクスポートしたいと思ったとき、 org-modeの8.3以降では方法が分らないという事がありました(以前のメモ)。 何気に検索してみると、AI回答に方法が示されていたので試してみたところ、所望の結果が得られたり。

#+BEGIN_SRC R :var data=R_data :file noexport_test4.png :width 640 :height 400 :results graphics :exports results
split.screen(c(1,2))
screen(1);pie(data[,2],labels=data[,1], clockwise=TRUE)
screen(2);barplot(data[,2],names.arg=data[,1])
#+END_SRC

[[./noexport_test4.png]]

*** データテーブル群 :noexport:
#+NAME: R_data
| a | 0.35 |
| b | 0.45 |
| c |  0.1 |
| d |  0.1 |

どういう事かと言うと、適当なセクション(この例では「*** データテーブル群」)を用意して、 そのセクションは丸ごとエクスポートしない、でも表R_dataは参照できるので、 Rブロックではグラフ画像が生成され、そのグラフ画像だけを参照するようなHTMLが生成される という事のようです。応用の範囲という感じかも知れませんが、もっと直観的に 「#+NAME: R_data :exports none」とかにはならないのだろうか?と思わなくはありません。 しかしながら、データをビジュアライズするためのプリプロセッサとしてorg-modeを使うのが 少し手軽になるような気はします。

2026/01/11

AM中に起床。

掃除したり。

ちょっとだけ「Emacsの雑記」を更新しました。 最近のハングの件とか、パッケージのImageMagickが更新されたのに対応したパッチ更新とか、 本文のマイナーな更新を行いました。Emacs本体のパッチの更新はありません。御参考まで。

よく見るとDMDの2.112.0がリリースされてるみたい (Change Log: 2.112.0)。
インストールして手持ちのコードでICE落ちする件 (以前のメモ1, 以前のメモ2) がどうなっているか確認してみたのですが、 状況変わらず。

$ dmd -m64 -O -I. -version=Unicode -version=Windows10 -version=IE5   -c GameFrame.d -of=GameFrame.obj
tym = x14
Illegal instruction

$ dmd --version
DMD32 D Compiler v2.112.0
Copyright (C) 1999-2025 by The D Language Foundation, All Rights Reserved written by Walter Bright

「-O」を付けなければ大丈夫そうなのも変わらず。コピーライトの年号が2025のままなので内容的には betaと同じレベルのものがリリースされてそうな予感。 因みに再現する最小コードは作れていません。他の人が同様の事象に遭遇する事に期待したいのですが....

2026/01/10

AM中に起床。

アパート契約更新にお出かけ。ほどなくして手続き完了。

以前、sortコマンドのフィールドの解釈がよくわからないという事を 記したのですが、そういやと思い ローカルLLMのgpt-oss-safeguard:120bで 「sortコマンドで行頭に任意数の空白文字があるとき、第1フィールドはどういう文字列と解釈されますか?」 と聞いてみたところ、行頭の空白文字は無いものと見なされるという返事が返ってきました。 例として以下のように記されていたのですが、

#+begin_src bash
$ cat file
    banana 2
apple 10
   cherry 30

# 第1フィールドで文字列比較(行頭空白は無視される)
$ sort -k1 file
apple 10
banana 2
cherry 30
#+end_src

実際にやってみるとそうはなりません(結果行の行頭空白文字が削られているのは御愛嬌だとは思いますが)。 実際にやってみると以下のようになります(coreutilsのsort。CygwinもLinux(Fedora)も同じ)。

$ cat sorttest.txt
    banana 2
apple 10
   cherry 30

$ sort -k1 sorttest.txt
    banana 2
   cherry 30
apple 10

GoogleのAIモードで聞いてみたらどうか?と思い試してみたところ、違う答えが返ってきました。
sortコマンドの第1フィールドの解釈 AI回答
こちらの説明の方が正しいと思われます。実際に第1フィールドの文字列に行頭からの空白文字が含まれていれば 前述のようなsort結果になるし、-bオプションを付けると、

$ cat sorttest.txt
    banana 2
apple 10
   cherry 30

$ sort -k1 -b sorttest.txt
apple 10
    banana 2
   cherry 30

となりますので、実際の動作とも合っています。でも、いちいち-bを付けないとダメなのはやっぱり面倒臭いです。
因みにEmacsには sort-fields や sort-numeric-fields というコマンドがありますが、 前述のデータに対して「C-u 1 M-x sort-fields」を実行すると、「sort -k1 -b」と同じ結果が得られます。 とはいえ、sortコマンドのように複雑な条件を指定することはできないので適材適所という感じかも知れません。 フィールドの区切り方の違いがある点は認識しておかないとダメな事に変わりはありませんが。

infoで sort-fields の事を調べていたら、reverse-region というコマンドがあるのを知りました。 昇順でソートされた後に全体を逆順に入れ替えることで降順のソートを行ったのと同じにするのに使うっぽいです。 「tac」という「cat」の逆順出力コマンドの存在は知っていたので、 稀に「C-u M-x | tac」で逆順にする事はあったのですが、reverse-regionがあるのも覚えておこう。


Cygwinの3.6.6がリリースされていたり。 3.6.5では負荷をかけるとEmacsがハングするのでパッチをあてているのですが、 3.6.6でどうなるかを確認。 アナウンス によればいくつかデッドロックに関する修正が行われているようですが、Emacsハングに関連しているのかは分らず。 一応 3.6.6にもパッチを当てたcygwin1.dllもビルドしておいたり。さてどうなるか.....?

gdb上でemacsを実行すると謎のSIGTRAPが通知される件もどうなっているか確認してみたのですが、 やっぱり謎のSIGTRAPが通知されるままで変わらず。

Cygwin3.6.6でのEmacsハング再現確認。結果から言うとハング再現しました。デスクトップPCとノートPCの 両方で確認していましたが、ノートPCの方で再現したので 先にパッチをあてたcygwin1.dllに差し替えて ハングしない事の確認に切り替えたり。いずれデスクトップPCの方も再現すると思われますが確認継続。

ほどなくしてデスクトップPCの方でもハングが再現したので、こちらもパッチをあてたcygwin1.dllに入れ替え。 まだ当面はパッチを外すことはできなさそう。

2026/01/09

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

Web巡回して終了。

2026/01/08

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

調べごとをして終了。

2026/01/07

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

調べごとをして終了。

2026/01/06

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

ちょろり実験コーディング。

2026/01/05

AM中に起床。今日までお休み。

掃除したり。

微妙に不調。

2026/01/04

AM中に起床。

「オトメの帝国(20)」。まさか2周目に入るとは思っていませんでしたが最終巻です。

「推しが武道館行ってくれたら死ぬ(12)」。 「おまえは好きな相手が同じ次元にいるだけでありがたいと思え」(以前のメモ) は個人的に名言と思っています😅。この頃はアニメやドラマになるとは全く想像していませんでしたが。 こちらも最終巻です。

2026/01/03

AM中に起床。

たまたま観た「ミッシング・リンク」というアニメ映画。ずっとCGアニメーションだと思って 観ていたのですが、エンディングロールでストップモーションアニメーションだというのが分り マジでか?と思ったりも。 制作スタジオの「ライカ(Laika)」(Wikipedia) で、画像検索してみると あれもこれもそういやそうだと 気づく感じでした。

Inkscapeでいわゆる等角投影図(アイソメ図)を描く用のグリッド表示ってできるんだっけ?と思って 調べてみたらちゃんとできるようです(参考ページ)。 でも、グリッド設定ではなくて図の角度設定で描いている例も意外と多いみたいです。

先週知った通り、Eテレで放送されていた「AKIRA」を観たり。 今の技術を使うとどうなるだろうか?と思います。

2026/01/02

AM中に起床。

ぐうたら過ごして終了。

2026/01/01

あけましておめでとうございます。今年もよろしくお願いいたします。

EmacsのIMEパッチと「Copilot Keyboard」の組み合わせで長い文を入力するとスローダウンする件。 なんとなく条件があるっぽい。 一つは「nyan-modeでアニメーション表示をしている」と再現し易いみたい。 再現している状態でウインドウメッセージを観察していると「WM_IME_NOTIFY(0x0282)」だけで 埋め尽くされる状況になっている、という感じの模様。 WM_IME_NOTIFYに絞ってwParamを確認してみたところ、「0xf」というパラメータ値で大量にメッセージが 送られてきているようでした。ただ、この0xfという値のパラメータについては定義が無くて、 どういう目的でどのような時に送られてくるメッセージなのかが分らず。 因みに0xfのパラメータは元のMS-IMEでも送られてくるので「何かわからないけどそういうもの」 なのかも知れません。

nyan-modeとの因果関係がわからないと思ったのですが、もしやと思い nyan-animation-frame-interval というアニメーション速度を調節するカスタム変数の値を少し大きくしてみた (==アニメーションスピードを下げた)ところスローダウンが軽減されるようです。 どうやら WM_IME_NOTIFYの発生は Emacs側にも関係しているようで、Emacs側で何かしら描画に関する処理 (例えばnyan-modeの描画だったりカーソルのブリンク表示だったり)が行われるとメッセージが発生しているようです。 nayn-modeを止めて且つカーソルのブリンク表示が止まった状態であれば、Emacs側起因ではメッセージは発生しないようで、 文字入力したタイミングに合わせたメッセージのみが発生しているようでした。 この場合のメッセージ処理はIMEのものしか無い為、待たされてスローダウンすることも無いようです。 いずれにしてもMS-IMEの時には問題になるようなことは無いので、Copilot Keyboard特有の現象のように思えます。

nyan-modeはいつも(nyan-start-animation)で使用しているのですが、(nyan-stop-animation)すると 何も表示されなくなるなぁ?というのに気づいたり。 Emacs29からできるようになった 「C-M-<wheel-up> や C-M-<wheel-down> でフレームやウインドウのサイズはそのままに フレームのフォントを大きくしたり小さくしたりする」 機能に対応する為にパッチを当てていたのですが、アニメーションしない場合の処理がバグっていました。 修行が足りません🥺。


TOP PREV