昔の最近の出来事(2026.02)

2026/02/28

AM中に起床。

ちょろりコーディング。

Copilot Keyboardのアップデート内容。MS Storeの説明に記されてました (参考)。 「一部アプリでクラッシュの修正」というのがありますが、どのような事象だったのだろう？ というのは気になります。

2026/02/27

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

Copilot Keyboardのアップデートが来ていたの入れてみたり。Windowsの再起動が必要なのは変わらず。
前回から変わった点や新規追加案件、思ったことをメモっておこうと思います。


ちょっと使った感じでは操作感の変化は感じられず、良くも悪くもなっていないみたいです。 何が変わったのかアナウンスがあると嬉しいのですが、今のところ(2月27日 24:10時点) Windows Blogsとかに新しい記事は無いようです。
....とか書いて試していたのですが、覚えていた事が少し忘れられている？ 特にCopilot Keyboardでは「へんかん」の第一変換候補が「返還」になる率がなぜか高い。 顔絵文字もよく使うのを意図的に変換して頻度を上げていたのが初期化されているようです。

2026/02/26

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

ちょろり実験コーディング用の仕込み。

2026/02/25

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

調べごとをして終了。

2026/02/24

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

Web巡回して終了。

2026/02/23

AM中に起床。

Copilot Keyboard。以前のメモの補足。 長い文章を入力していると、そのうち先頭の方は自動的に変換確定するのですが、その時に一瞬入力フォーカスが 失われてしまうのか、入力を取りこぼしてしまうことがあります。入力しているその瞬間の文字が失われている 場合もあるのですが、変換を行うときに失われる場合もあるようで、おかしな変換結果になっていて 初めて入力文字が消えているのに気づくという感じです。 これが解消されれば ひたすら入力を続けて変換性能を見ることが可能だと思われます。 因みにMS-IMEでは取りこぼしは発生しないようです。

「シン・エヴァンゲリオン劇場版𝄇 TV版」。なんでTBSでの放送なのだろう？とは思ったりも。 番組最後に完全新作シリーズを制作することが発表されましたが (公式)、それと関係があるのだろうか？ Webで検索してみると 真偽のほどはわかりませんが、劇場公開後は Amazon Prime Videoでの独占配信だった事と、 Amazon Prime Videoと TBSは関係がある事などからTBSでの放送が可能になった....というのがもっともらしい感じがします。 そういや ヱヴァンゲリヲン新劇場版 はインディーズ映画だったのを忘れてた。本来、TV放送局に縛られる必要は 無いのかも知れません。

2026/02/22

AM中に起床。

掃除したり。

以前、テーマのカスタマイズメニューで使用している ボタンのSVG描画が変になっているということを記したのですが、 修正されたようです(修正コミット)。 コミットコメント的には reverts commit となっているので、壊していたということなのか？🤔 それにしても以前にも記したことがありますが、 revertすることが多いなぁとは思います。

2026/02/21

AM中に起床。

ちょろり買い物にお出かけ。

Copilot Keyboardを普段使いしてみているのですが、打ち間違えなければ今のところ変換精度は良いかもしれません。 打ち間違ったまま変換してしまうと直せないので、その時はあきらめて変換確定してから 部分修正するしかないのですが、恐らく多くの人はIMEの編集状態で修正することはしていないと思うので、 打ち間違いのあるまま変換して直せなくても問題とは思われないかもしれません (そして変な変換候補が覚えられてしまう)。 最新バージョンではCtrl-hがバックスペースになったので、一つ前のバージョンの時のように打ち間違いを直すつもりが Emacs本体にパススルーされて元の文書の方を壊してしまうということが起こらなくなったのが 個人的には都合がよくなったと思うところです。後、IME入力中も「無変換」と「変換」で英数とローマ字を 切り替えられるのが一番良いと思ったところです。むしろMS-IMEの方で「無変換」を押してカタカナに なってしまうことが、MS-IMEを使用している本物お仕事の方で弊害が出ているかもしれません😓。
以前のメモに記したEmacsで辞書表示(候補の説明表示)できない件については特に調べていません。 当面はCopilot Keyboardのバージョンアップの度に確認してみようと思ってますが、 メモにも記した通り変な事が入り込む余地も無いように思えるので、どうやって調べたもんか？というのはあります。

2026/02/20

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

Web巡回して終了。

2026/02/19

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

調べごとをして終了。

2026/02/18

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

調べごとをして終了。

2026/02/17

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

Web巡回して終了。

2026/02/16

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

Web巡回して終了。

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で変な制御をしてないか？が疑われるとは思います。 ところで、「辞書が表示されない」と表現するとユーザー辞書などの話と区別がつかなくなりそうなのですが、 正式になんて言うのかわからなかったので、一応スナップショットを取っておきました。

Emacsでの期待しない動作;単語の意味が表示されない テストアプリでの期待通り動作;単語の意味が表示される

変なことをするにしても、何をやればこんなピンポイントで変なことになるんだ？感はあります。

AI回答によると 「その小さな意味表示は、IMEの変換候補ウィンドウ（または予測候補ウィンドウ）に付随する候補の説明表示（ツールチップ）と呼ばれます。」 だそうな。要するに名前は無いらしい。言語化するのに不便です。

2026/02/07

AM中に起床。

掃除したり。

Webを散策していたら、Copilot Keyboardのバージョンアップが出ているらしいというのを知り 確認してみたら確かに来ていたので入れてみたり。Windowsの再起動が必要なのは変わらずです。 さておき、アップデートを知った 記事 によると、ショートカットが MS-IMEと同じ感じになったみたい。 因みに Japan Windows Blog の記事は こちら。 また、特定のアプリでスローダウンする現象(個人的に確認したものではxyzzyはスローダウンしてました)が解消 されているという事だったので、Emacsで長い文章を入力してどうなるか確認してみたのですが、 やっぱりスローダウンするようです。
前回からの違いや、思ったことをメモっておこうと思います。


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の呪いが強すぎる。

TOP PREV