2026/02/15
AM中に起床。
掃除したり。
Emacsのガベージコレクタが動作に影響することってあまり無いように思っているのですが、
影響することってあるんだっけ？と思い検索していると、
AI回答の中に「profiler-start」というコマンドがあるのを知りました。
「profiler-start」で開始して「profiler-stop」で止めた後、「profiler-report」で結果を表示する
という感じで使うようです。TANEが使っていて明らかに遅いと思っているのは magit なのですが、
起動からログを眺めるところを実行して結果を見てみたところ以下のような感じでした。
=== Memory-Profiler-Report
32,539,933 56% + redisplay_internal (C function)
14,623,143 25% + command-execute
9,936,206 17% + timer-event-handler
9,834 0% Automatic GC
3,294 0% + ...
749 0% + transient--pre-command
480 0% + magit-section-post-command-hook
48 0% + eldoc-schedule-timer
42 0% + help-command-error-confusable-suggestions
=== CPU-Profiler-Report
62381 84% + command-execute
8160 10% + ...
3264 4% + timer-event-handler
330 0% Automatic GC
76 0% redisplay_internal (C function)
因みに、実際にはMemoryとCPUが別バッファで開くので、手で内容を写した感じです。
単純にコマンド実行が遅いという結果のようです。Automatic GCは実行されていますが、
ほぼゼロという事のようです。メモリの使用量は redisplay_internal が半分を占めているようですが、
ダブルバッファリングとかにかかっているのかしら？ どちらにしてもGCが問題ではないことだけは言えそうです。
2026/02/14
AM中に起床。
ちょろり実験。
長い文章をローマ字入力して漢字に変換する想定で、ひらがなで書かれた文章をAIにかな漢字変換
させてみるとどうなるか？と思って試してみたり。
元の文章は こちら の
準2級の速度問題の最初から6行分を使用させていただいてます。横長テキストですが以下のような感じになりました。
================================================================================
[原文]
とても広い南米大陸は、さまざまな自然や美しい景色を見ることができる地域です。その中心には、日本の本州とほぼ同じ大きさで世界最大級とされる湿原があります。雨季に入ると、川からあふれ出した水が、平原をひたひたと満たしていき、全体の8割以上を覆い尽くしていきます。やがて乾季になり、だんだん水が引き始めると、そこにはさまざまな形の池や水辺が残ります。
================================================================================
[Copilot Keyboardで変換修正無し(参考)]
とても広い南米大陸は、さまざまな自然や美しい景色を見ることができる地域です。その中心には、日本の本州とほぼ同じ大きさで世界最大級とされる湿原があります。雨期に入ると、川からあふれ出した水が、平原をひたひたと満たしていき、全体の8割以上を覆いつくしていきます。やがて乾季になり、だんだん水が引き始めると、そこには様々な形の池や水辺が残ります。
================================================================================
[ローマ字入力元]
totemohiroinannbeitairikuha,samazamanasizennyautukusiikesikiwomirukotogadekirutiikidesu.sonotyuusinnniha,nihonnnohonnsyuutohoboonajiookisadesekaisaidaikyuutosarerusitugenngaarimasu.ukinihairuto,kawakaraafuredasitamizuga,heigennwohitahitatomitasiteiki,zentaino8wariijouwoooitukusiteikimasu.yagatekannkininari,danndannmizugahikihajimeruto,sokonihasamazamanakatatinoikeyamizubeganokorimasu.
================================================================================
[自作のELISPで上記ローマ字入力元をひらがな化]
とてもひろいなんべいたいりくは、さまざまなしぜんやうつくしいけしきをみることができるちいきです。そのちゅうしんには、にほんのほんしゅうとほぼおなじおおきさでせかいさいだいきゅうとされるしつげんがあります。うきにはいると、かわからあふれだしたみずが、へいげんをひたひたとみたしていき、ぜんたいの8わりいじょうをおおいつくしていきます。やがてかんきになり、だんだんみずがひきはじめると、そこにはさまざまなかたちのいけやみずべがのこります。
================================================================================
[Ollama + gpt-oss-safeguard:120b に以下のように指示して漢字変換]
* ** 以下の日本語のひらがなで記された文章を文脈に適した漢字やカタカナを使った文章に変換してください。このとき、補足文の追加や読み替えは行わないでください(例えば「オレンジ色」を「橙色」とするような読み替えはしない)。
------
とてもひろいなんべいたいりくは、さまざまなしぜんやうつくしいけしきをみることができるちいきです。そのちゅうしんには、にほんのほんしゅうとほぼおなじおおきさでせかいさいだいきゅうとされるしつげんがあります。うきにはいると、かわからあふれだしたみずが、へいげんをひたひたとみたしていき、ぜんたいの8わりいじょうをおおいつくしていきます。やがてかんきになり、だんだんみずがひきはじめると、そこにはさまざまなかたちのいけやみずべがのこります。
------
とても広い南部大領域は、様々な自然や美しい景色を見ることができる地域です。その中心には、日本の本州とほぼ同じ大きさで世界最大級とされる湿原があります。海に入ると、川からあふれ出した水が、平原をひたひたと満たしていき、全体の8割以上を覆いつくします。やがて乾期になり、だんだん水が引き始めると、そこには様々な形の池や水辺が残ります。
================================================================================
[Google AIモードで以下のように指示して漢字変換]
かな漢字変換してください。
とてもひろいなんべいたいりくは、さまざまなしぜんやうつくしいけしきをみることができるちいきです。そのちゅうしんには、にほんのほんしゅうとほぼおなじおおきさでせかいさいだいきゅうとされるしつげんがあります。うきにはいると、かわからあふれだしたみずが、へいげんをひたひたとみたしていき、ぜんたいの8わりいじょうをおおいつくしていきます。やがてかんきになり、だんだんみずがひきはじめると、そこにはさまざまなかたちのいけやみずべがのこります。
とても広い南米大陸は、様々な自然や美しい景色を見ることができる地域です。その中心には、日本の本州とほぼ同じ大きさで世界最大級とされる湿原があります。雨季に入ると、川から溢れ出した水が、平原をひたひたと満たしていき、全体の8割以上を覆い尽くしていきます。やがて乾季になり、だんだん水が引き始めると、そこには様々な形の池や水辺が残ります。
================================================================================
Copilot Keyboardは参考としています。というのも、一度正しい変換を行ってしまうと間違わなくなってしまうので、
「厳密に初めての状態」を作り出すことができなかったからです。
あと、変換キーを押さずに自動変換確定を行っていると、候補ウインドウの移動などが伴ったときに
入力した文字を一部ロストしてしまうようです。意図せず誤入力となってしまうのでイマイチです。
で、Ollama + gpt-oss-safeguard:120b の方ですが、読み間違いをしている部分や意味的に変わらない
読み替えをしていて微妙な感じです
(「なんべいたいりく」を「南部大領域」、「うきにはいると」を「海に入ると」、
「おおいつくしていきます」を「覆いつくします」、「乾期」と「乾季」は同じ意味なのでOK)。
あと、時間は結構かかりました。時間に対する結果としては大分イマイチというのが個人的な感想です。
何気にGoogle AIモードで試してみたら、こちらは ほぼ一瞬で良好な変換結果が得られました。
このレベルの変換ができるのであれば、変換結果を気にせずに入力に集中できるかもなとは思いました。
そういや、ひらがなの文章を再変換すれば長文の変換性能が分るんじゃね？と思ったり。
MS-IMEでは再変換前の文字列を程よい長さ(長すぎるとダメ)で選択して「Win + /」で再変換できるようです
(最初、AIに「Win + \」だ と言われてできなかった)。ただ、Copilot Keyboardでは機能しませんでした。
できるようになったらまた試してみたいと思います。
ローマ字入力文字列をかな文字列に変換するプログラムを作っていて、
「ゐ(wyi)」や「ゑ(wye)」ってどうやって入力するんだっけ？と思って調べたら、
MS-IMEやCopilot Keyboardでは記したように入力するという事だったり。
「wyevangeriwonn」でカタカナにすれば「ヱヴァンゲリヲン」になるという事で、
一時的には覚えたけど使わないとすぐに忘れそう😓
2026/02/13
テレワーク。早めに終了。
Emacs31系になる予定のmasterブランチのNEWSに、MS-Windowsでカラーフォントのサポートについて
記されている項目があり、w32-inhibit-dwriteというカスタム変数でカラー表示を無効化できる旨が
記されています。しかし、CygwinでビルドしたEmacsで変数を調べてみてもそんな変数は無いと
エラーするようだったので調べてみたり。どうやら WINDOWSNTのdefineのみ定義されるようなコードに
なっていて、Cygwinビルドの時には定義がスキップされている模様。ちょろっと直して
CygwinビルドのEmacsでも表示切替ができるようになってみたり。
そういやEmacs31はいつリリースする予定なのだろう？ Windowsビルド向けにカラー絵文字の対応が
公式に入ってからもう1年半が経過する(以前のメモ)
のだけれど.....
2026/02/12
テレワーク。早めに終了。
調べごとをして終了。
2026/02/11
AM中に起床。
そういや今日はWindowsUpdateが来る日か。プライベートPCで昼間にWindowsUpdateをする事は
ほとんどないので新鮮な気も。
なんかセブンイレブンのおにぎりの値段が しれっと上がってるなぁ？
Copilot Keyboard。ワープロ検定の問題文(参考)
を、句点ぐらいまでを続けて入力したときの変換の様子を見てみたり。
概ね良好に変換されるようですが、「貼る/張る」「宛てる/充てる」「送る/贈る」など、前後の文脈が
理解されていれば間違わないような誤変換はあるなという感じ。あと、意外と「変換しない」方向に向いてい
るような気もします。例えば「わかりません」とか。
続けて文章を入力しているとそのうち間違わなくなるのは頻度で選んでいるところもある
からだろうとは思います。まぁ、LLMも統計データの塊だとは思いますが。
以前にも記したことがありますが、変換せずに入力を続けていると
始めの方の文は自動的に変換確定します。句点(。)までの一文が長いものがギリギリ入りきらないくらいなのは
MS-IMEと同じ感じのようですが、読点(、)までをひと固まりとする感じでも無いようです。
この辺のぶった切り方から想像しますに、文脈を理解して変換候補を決めている訳では無いのかもしれません。
もしワープロ検定の文章を誤変換無く変換できるレベルになれば、変換効率の良さを体感できるかも知れません。
文脈が把握されていれば間違えない例はいくつかあると思います。例えば
「たこのえがえがかれたたこをあげる」は「蛸の絵が描かれた凧を上げる」一択だと思いますし、
「はしのはしをあるく」は「橋の端を歩く」一択だと思います。Copilot Keyboardはパターン的に覚えている
感じがしなくはありませんが、一回正しく変換すれば 次からは間違わないようです。
入力補完と変換候補の表示が混在になっているのはどうにかできないかなぁ？と思ったり。
例えば「Copilot Keyborad」を何度か入力していると「Co」を入力した段階で候補に「Copilot Keyborad」
が出てくるようになるのですが、そこで選択してしまうと長文入力が途切れて
(漢字ではありませんが)単漢字変換になってしまいます。
結果的に「Copilot Keyborad」を主語とするような長文入力ができないということになります。
例えば、TABやカーソルキーで選択している間は「入力補完」で、スペースキーを押した場合に「変換」という
ような状態遷移にすれば、補完を交えながら長い文章を入力することができるかもなぁ？
とは思ったりも。そんなにうまくいくかは分りませんけれども。
GIMP 3.0.8を立ち上げるとアップデートの案内が表示されたのですが、マイクロバージョンが
上がるのではなく revisionが上がるという、今まで無いパターンのアップデートが来ていたり。
アイコンの表示も「GIMP 3.0.8-2」となりました。何が変わったのかはよくわからず。
2026/02/10
テレワーク。早めに終了。
minttyでscreenコマンドを実行したときにminttyのバックスクロールが封印されている話。
screenコマンドがオルタネート画面を使用するかららしい。
封印を解くにはには .screenrc に「termcapinfo xterm* ti@:te@」を追加すればよいという
AI回答があったので、試してみたら確かにminttyのバックスクロールが有効になりました。
ローカルマシンのターミナルにminttyを使用して、リモートマシンでscreenコマンドを実行しているような場合、
screenのバックバッファをローカルマシンのクリップボードにコピーしたいと思ってもできません。
こういう場合はローテクにターミナルのバックバッファをマウスで選択してコピペするのが一番簡単です。
因みに、Cygwinでローカルに起動した screenコマンドのバックバッファの内容をクリップボードに入れたい
場合は screenのバックバッファをコピーモードで選択した後、「: writebuf /dev/clipboard」とすれば、
Windowsのクリップボードにバッファの内容をコピーできるようです。これを使えば良いんじゃないか？
と一瞬思ったりもするのですが、ローカルとリモートの間でネットワークが切れるのを想定した場合、
screenはリモート側の方で起動せざるを得ないのでダメかと思い直したり。
screenコマンドが .screenrc を読み込むタイミング。原則は最初にscreenコマンドを起動した時に
.screenrcは読み込まれ、アタッチし直す場合には読み込まないらしいのですが、
先の termcapinfo などターミナルに関する設定は例外的にアタッチ時にも読み込まれるようです。
なんで？と思わなくもないのですが、例えば最初にscreen起動したときはxtermだったけど、
一旦デタッチして、再度アタッチする時にvt100とかになっているかも知れないみたいなのに
対応できるのかな？と思ったりも。
わざわざ例外的に読み込む仕組みが入っているのには深い理由があるのでしょう。
「Copilot のキャラクター機能はCopilotKeyboardに集約されます」
というblog記事。むしろ copilot.com が何なのかを知らないTANEですが、そういう事になっているらしい。
それはともかく、Copilot Keyboardって日本語以外の入力もサポートされるということなのかしら？
英語圏の人たちは Copilot Keyboard は使わないのだろうと思ってました
(即ち、英語圏の人たちは見かけ上 Copilotのキャラクター機能だけが無くなる)。
ところで、翻訳機能がついているとの事で試してみたのですが、確かにテキストを選択するとプルプルしている
のですが、クリックしても検索しようとするだけで翻訳はしてくれないようでした。どうなるのが正解かは不明。
ものすごく久しぶりにlibjxlのアップデートリリースが出ている模様
(v0.11.2)。
セキュリティ対応的なアップデートみたい。
検索してて知ったのですが、ChromeでJPEG XLの採用が再検討されているらしい
(参考記事)。
周りの状況というのもあるかも知れませんが、WebPも結局JPEGを置き換えるには至っていないしなぁ
とは思います。とは言え恐らくJPEGはもう無くならない気がします。
だって、既存のコンテンツはJPEGのままなので、
サポートをやめたら、表示できないページだらけになってしまう
→そんなブラウザは使われない→ブラウザの方が死ぬ という論法。
2026/02/09
テレワーク。早めに終了。
以前のバージョンのMS-IME。
こちらのページの存在を知りました。
「以前のバージョンのMiccrosoft IME」の設定には、英字や数字を常に半角に変換する設定があるらしい。
括弧についても設定できるようなので、かなり細かくどのように変換するかを指定できるみたい。
これをそのまま移植した上で 変換効率だけを上げてくれればよいのにと思わなくもありません。
Emacsの「C-u」で数値を入れたのち、文字やコマンドを入力すると数値の数だけ文字入力やコマンド実行が
行われます。viで実行したい回数を値で入れてからコマンド実行するのに似たことができます。
なのですが、なぜかC-y(yank)は期待通りの動作が行われないなぁ？と思ったり。なんでだ？🤔
一旦キーボードマクロでyankを1回実行したものを記録して、C-uで回数を入力したのちマクロ実行すると、
見かけ上指定回数だけyankを実行したようには振る舞うようです。
正確に多くの回数実行しなくてはならない場合には良いかもしれませんが、
10回以下なら数えながらC-yを押してしまうな😅
2026/02/08
AM中に起床。雪が積もってるな。
ちょろり投票にお出かけ。雪は舞っていましたけど道路に積もってはいなかったのでよし。
17分ほどで帰着。
先週買ったラピッドトリガのキーボード。1週間ほど使ってみましたが、
突っかかりを感じるキーが無く非常に快適です。
アクチュエーションポイントやラピッドトリガの反応距離などは少し弄ってみたりはしていますが、
大きく変化を感じるようないじり方では無いので、効果のほどはわかりません。
先日Copilot Keyboardで変換/無変換キーを入力中にローマ字/半角英数の切り替えに使えるのを知りました。
ところが、ラピッドトリガのキーボードだと隣のスペースキーと押し間違えることがあるな？と思い、
Realforce R4(本物お仕事用)と比べてみると、ラピッドトリガの方は変換/無変換キーの幅が若干短いようです。
物理的な幅は変えられないので、普段使いのラピッドトリガの方で慣れるしかないかとは思ったりも。
おそらく幅の短いラピッドトリガの方で慣れれば、Realforceの方は問題無いだろうと思います。
普段使いのEmacsは30.2なのですが、Copilot Keyboradを使っていると長い文章の入力でスローダウンするので、
実験的に 「WM_IME_NOTIFY(0x0282)」のwParam「0xf」を捨てるパッチを当てて使ってみることにしました。
打ち間違えると面倒臭いことにはなるのですが、少し使ってみて 誤変換は少ないように感じたので、
プライベートの文書作成で Copilot Keyboardを普段使いしてみようと思います。
Copilot Keyboardで辞書が表示されない件。観察用のスケルトンコードをいじったりEmacs本体をいじったりして
何か反応するものがないかを試してみているのですが原因はつかめず。
というか、変な事が入り込む余地も無いような気がするのですが...？🤔
Copilot Keyboardのバグなのかも知れませんが、手元で試している範囲内ではEmacsだけがダメなので、
普通に考えればEmacsで変な制御をしてないか？が疑われるとは思います。
ところで、「辞書が表示されない」と表現するとユーザー辞書などの話と区別がつかなくなりそうなのですが、
正式になんて言うのかわからなかったので、一応スナップショットを取っておきました。
変なことをするにしても、何をやればこんなピンポイントで変なことになるんだ？感はあります。
AI回答によると
「その小さな意味表示は、IMEの変換候補ウィンドウ（または予測候補ウィンドウ）に付随する候補の説明表示（ツールチップ）と呼ばれます。」
だそうな。要するに名前は無いらしい。言語化するのに不便です。
2026/02/07
AM中に起床。
掃除したり。
Webを散策していたら、Copilot Keyboardのバージョンアップが出ているらしいというのを知り
確認してみたら確かに来ていたので入れてみたり。Windowsの再起動が必要なのは変わらずです。
さておき、アップデートを知った
記事
によると、ショートカットが MS-IMEと同じ感じになったみたい。
因みに Japan Windows Blog の記事は
こちら。
また、特定のアプリでスローダウンする現象(個人的に確認したものではxyzzyはスローダウンしてました)が解消
されているという事だったので、Emacsで長い文章を入力してどうなるか確認してみたのですが、
やっぱりスローダウンするようです。
前回からの違いや、思ったことをメモっておこうと思います。
- バージョンは1.0.0.3078
- 長い文章を入力するとスローダウンする件は状況変わらず。
「WM_IME_NOTIFY(0x0282)」のwParam「0xf」が大量に送られてくるのを
wParam==0xfを選んで捨てればスローダウンを軽減できそう(実際に軽減される)なのも変わらず。
- 「Ctrl + Space」が何かしらCopilot Keyboardに食われていたのは解消されました。
「Ctrl + Space」を「なし」にする設定が正しく機能するようになったようです。
- CygwinのEmacsでは変換候補の中に辞書が表示可能なことを示すアイコンが表示されている単語でも
辞書が表示されないのも変わらず。
MinGWでビルドしたEmacsでもダメっぽい...🤔
- 長い文章を入力していると、途中で入力がキャンセルされてしまう事があるようです。
- 前は記していませんでしたが、文節移動や入力ミスを訂正するショートカットはまだ実装されていないようです。
こちらの参考ページ
でいうところの「Ctrl a,s,d,f,k,l,z」辺り。
文節移動は「カーソルキー←→」、文節の伸縮は「Shift + カーソルキー←→」で出来るので、
(入力ミスではない)誤変換を訂正することは可能なようです。
- 誤変換で覚えてしまった予測候補を削除する機能はショートカット(Ctrl + Delete)で対応されているようです。
むしろMS-IMEでこのショートカットがあるのを知らなかった😅。
予測候補メニューからマウス操作で消す事もそのうち可能になるんじゃないかと思われます。
- MS-IMEの時には変換候補を変えると wParam=IMN_CHANGECANDIDATE が連動して送られてくるのですが
Copilot Keyboard では送られてこない件は未確認(調べるのにデバッグコードを仕込む必要があるのと
Emacsではそれで困ることが今のところないので)。
- 絵文字の変換候補がカラー表示じゃないのはなんでだ？
- 変換候補が5つしか表示されないので、山ほど候補のある「かお」で顔絵文字を探そうとするとなかなか見つけられない。
C-SPCが食われなくなったのと、C-hがIM編集でバックスペースとして機能するようになったので、
打ち間違えなければ MS-IMEと同じレベルで使用できそうです。
Copilot Keyboard では「変換キー を IME-オン」と「無変換キー を IME-オフ」のキー割り当てが
IM入力中でも機能するようです。例えば、「ビルドにはconfigureとmakeを使用します」と入力＆変換したい場合、
「birudoniha<無変換>configure<変換>to<無変換>make<変換>wosiyousimasu<Space>」
と入力すれば良いようです。
MS-IMEの場合「birudoniha<無変換>」とした時点で「ビルドニハ」とカタカナに変換されてしまうので
同じ事をしようとすると<無変換>の代わりに<半角/全角>を使用するしかありませんでした。
むむ、これは Copilot Keyboard の方が良いぞ？
Copilot Keyboard + Emacsで辞書が表示されない件を調べてみたり。といってもEmacsで調べると
正しい状態が分らないので、C言語でWindowsメッセージを観察するスケルトンを作成してどんなメッセージが
到達するのかを観察してみたり。とりあえず 送られてくる全てのメッセージをprintf()で表示
しながらIM操作を行ってみたところ、辞書は表示されるのですが、辞書が表示されるときには
特にメッセージが送られて来てはなさげ。
捨ててはいけないメッセージを捨てている可能性を疑ったのですが、そういう訳ではないみたい。うーむ🤔
2026/02/06
テレワーク。早めに終了。
調べごとをして終了。
2026/02/05
テレワーク。気持ち早めに終了。
Emacsのモードラインにはバッファの文字コードと改行コードを示す表示が行われています。
「(DOS)」とか、「(Mac)」とか、(なぜかUnixだけ)「:」とかで示されていますが、
なぜ OS名なんだ？とは思ったりも。30年以上前のX68kのMicroEMACSとかでは「CRLF」のように
改行コードそのもので示されていたのでそれで良いのでは？とも思った次第。
ただ、CRLFじゃない場合「Macに持っていくときはCRだっけ？LFだっけ？」ってなりそうな気もするので
OS間でファイルを行き来する事がある場合は OS名で示した方が判りやすい気もしたり。
GUIモードのEmacsであれば、マウスカーソルをかざせば tooltipでもう少し詳しく表示されるので
「MacってCRだっけ？LFだっけ？」も確認できます。現在のmacOSはUnixと同じく(というかmacOSはUnixなので)
「LF」が標準になっているそうです。ただ、「改行コードは(Mac)になってれば良いんだっけ？」に対する説明は
「いや、かつての MacOS(現在はClassic MacOSと呼ばれる)では...macOSはUnixなので...」という感じで
ややこしい気がします。macOSは使ったこと無いのでわかりませんけど。
2026/02/04
テレワーク。気持ち早めに終了。
BIOSアップデートが来てたので入れたり。前回からの周期がやっぱり
短い気がします。旧PCではこんなにBIOSアップデートした記憶は無いのだけど。
2026/02/03
テレワーク。早くもなく遅くもなく終了。
「Emacsの雑記」を更新しました。
「半角/全角キー」によるIME状態切り替えの設定対応(以前のメモ)と、
wrapped_convertでJXL画像が表示できなくなっている件の対応(以前のメモ)について
更新しました。wrapped_convertについては、まだmagickコマンドのみにはしていないので、これまでの設定通りで
JXL画像表示に関する不具合のみが修正されるつもりです。ご参考まで。
2026/02/02
テレワーク。早めに終了。
そういえば矩形選択した位置に文字列を挿入する場合、Emacsだと矩形で1カラム×複数行選択しておいて、
「string-rectangle(C-x r t)」で文字列挿入できます。
vimでも同じ感じでできるだろうと思って C-vで縦に矩形選択した後、「i」で挿入モードにしたつもりですが反応無し。
「I(Shift+i)」じゃないとダメみたいですが、単純に「なんで？」とは思ったりも。
2026/02/01
AM中に起床。
掃除したり洗濯したり。
そういや新しいPCに msys2/MinGW 環境はまだ入れてなかったなぁと思い入れてみたり。
ひとまずEmacsをビルドできるくらいには整ってみたり。で、Emacs-30.2をビルドしてみるのですが、
MinGWのヘッダ類がアップデートされている影響を受けて 30.2 のソースコードは最新の UCRT64 環境では
コンパイルエラーになるようです。
これとか、
これとか、
strerrorに関するコンパイルエラーとか、に対応するパッチをあてる必要がありました。
概ね立ち上がるようになったのですが、
⛔ Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not available or failed to load [4 times]
というエラーメッセージが出たり。MinGW向けに libtree-sitter-*.dll が無いからだろうなと思い、
コンパイルしてパスの通った場所に置いたのですがワーニングが解消せず。なんだこれ？🤔
メッセージではどの言語のライブラリが見つからない/ロードできないと言っているのか判りません。
起動時にウインドウ分割してメッセージが表示されるので目障りなのですが、一旦放置。
gptelもそのまま使えるかと思って試してみたらHTTPステータスが400で返ってきてエラーしている模様。
「Ollama error: (HTTP/1.1 400 Bad Request) unexpected EOF」という事らしいのですが、なんのこっちゃ？🤔
GoogleAIで聞いてみたところ、JSONリクエストのエンコーディングの問題の可能性があるとのこと
だったので、提示されたprocess-coding-system-alistの設定を適用してみたのですが解決はせず。
しかし、Emacs上で ImageMagickのconvertコマンドを外部実行するにあたって、
「(modify-coding-system-alist 'process "convert" 'cp932)」
を設定する必要があった(以前のメモ)事から察するに、
「(modify-coding-system-alist 'process "curl" 'cp932)」とするとどうか？
と思って試してみたところ、うまく動作するようになりました。ShiftJISの呪いが強すぎる。
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で調べた時の
事象をメモっておくことにします。
- バージョンは1.0.0.2651
- 長い文章を入力するとスローダウンする件。
「WM_IME_NOTIFY(0x0282)」のwParam「0xf」が大量に送られてくるようなのですが、
それを DefWindowProc()にフォワードするとそのうちメッセージが処理しきれなくなる？
wParam==0xfを選んで捨てればスローダウンを軽減できそう(実際に軽減される)。
- 「Ctrl + Space」が何かしらCopilot Keyboardに食われている。
バージョン(1.0.0.2651)より前は無かった(ハズ)、設定→ショートカットの
「Ctrl + Space」を「なし」にしているけど 何かしら食われたままになっている模様。バグ？
- 変換候補の中に辞書が表示可能なことを示すアイコンが表示されている単語でも
辞書が表示されない。メモ帳とかでは表示されるので、emacs-w32のときだけダメっぽい。
Cygwinパッケージのオリジナルemacs-w32バイナリで「半角/全角キー」によりIME起動した場合でもダメっぽい。
原因不明。
ただ、MS-IMEの統合辞書と違って同音異義語/同訓異字を複数同時に表示してくれないので気が利いていない感じはします。
- MS-IMEの時には変換候補を変えると wParam=IMN_CHANGECANDIDATE が連動して送られてくるのですが
Copilot Keyboard では送られてこない。IMEパッチではそれで何かする訳では無いので問題ありませんが
何かしら見ているアプリでは思った動きにならないかも？
バージョンアップで問題なくなれば良いのですが、まだ当面の間は常用に耐えないなぁ...と思います。
全然関係ない流れでキーボードのスイッチに「磁気スイッチ」という方式のスイッチがあるのを知ったり。
以前、ラピッドトリガーなる方式の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」を選択すれば上の方に上がっては来るのですが、辞書を鍛える必要はあります。
また丸カッコや数字を含む場合も全角の方が優先される感じになっているので続けて入力するならば
意図的に「半角/全角キー」で切り替える方が結局修正の手間が無いので早いという結論になってしまう
かもという感じです。英数や記号を含む場合、半角を優先するような重みづけスイッチがあれば
大分様子は変わるかもしれません。実際にどうなるかはわかりませんけど。
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」とではコマンド解釈や処理に互換性が無くなっている部分があるようです。
- -auto-orient オプションの位置に互換がない。
「magick convert -auto-orient foo.jpg xxx.png」だと変換されますが、
「magick -auto-orient foo.jpg xxx.png」だとコマンドラインのエラーとなる。
「magick foo.jpg -auto-orient xxx.png」のようにオプション指定位置の修正が必要。
- LengthAndFilesizeDoNotMatchな BMPファイルの読み込みに互換がない。
「convert: LengthAndFilesizeDoNotMatch `./foo.bmp' @ error/bmp.c/ReadBMPImage/964.」
のメッセージが出るようなBMPファイルでも、
「magick convert ./foo.bmp xxx.png」ならばコンバートはできるのですが、
「magick ./foo.bmp xxx.png」ではコンバートできない(ファイルが生成されません)。
という訳で、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モードで聞いてみたらどうか？と思い試してみたところ、違う答えが返ってきました。
こちらの説明の方が正しいと思われます。実際に第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> でフレームやウインドウのサイズはそのままに フレームのフォントを大きくしたり小さくしたりする」
機能に対応する為にパッチを当てていたのですが、アニメーションしない場合の処理がバグっていました。
修行が足りません🥺。