本日休業。PM通院。診療が終わったら薬局が閉まっていたので明日また出かけなきゃ....
EdgeのCopilotで「絵を描いて」と注文すると絵を描いてくれますが、
仕組みとしては 表にGPTが居て、絵を描く必要があると判断した場合は DALL·E をバックエンドに使って
生成した絵を回答として返すという感じらしいです。
以前知ったfunction callingという仕組みなのだろうと思います。
この場合、画像生成器を持たないと絵は描けないという事になるのかな？と思ったところ、
AI回答によれば「SVG出力で良ければ簡単なイラストは描ける」....らしい。
という訳で Ollama+gpt-oss-safeguard:120b+gptel を使って
「○○のイラストをSVGで描いてください。」というリクエストをいくつか出してみました。
それで描かれたのが以下。
| 猫 | 魚 | デスクトップPC | ノートPC | スマホ |
|---|---|---|---|---|
gptelのチャットバッファはorg-modeで使用しているのですが、SVGのコードブロックをプリビューできないんだっけ？
と思い、検索してみたところ AI回答に org-babel を使えば可能というのがあったので試してみたのですが
ダメでした。
現状はob-svg.elなんて無いので無理なのですが、Emacs的にはやればできそうな気はします。
テレワーク。早めに終了。
そういえば、以前「emacs-anthy-unicode」なるものの存在を知り、
VMのFedoraはそちらに乗り換えていたのですが、そもそもどういうプロジェクトなのかはよく知りませんでした。
anthy-unicodeはこちらのGitHubプロジェクトでメンテナンス
されているようです。ところで、Languagesというプロジェクト内のファイルがどのような言語で書かれているか
を示す割合グラフが表示されますが、Rakuが 54.9% となっていて、え？マジで？と思ったり。
でも、ファイルを見る限りはほとんどがC言語のように思えたりも。どういうこと？
テレワーク。早めに終了。
先日、Copilotで「Copilotキャラクタのアクアを絵にしてみて」って
注文したら描いてもらえました。そういや ミカや エリンだとどうなるのかしら？と思って、
試してみたら、
「申し訳ありませんが、Copilotやその派生キャラクター（Copilot keyboardを含む）を題材にした画像の生成はお手伝いできません。」
という塩対応されました。しょんぼり。
アクア自身の説明をしていたので、その説明をイメージとしてキャラクターを絵にしてみてって
注文してみたら
「申し訳ありませんが、あなたが求めているキャラクターのイラスト生成はお手伝いできません。」
って言われてやっぱり描いてもらえず。残念。
テレワーク。早めに終了。
「神奈川に住んでるエルフ」のアニメでやってたゴミ収集車の音楽。
川崎市では「好きです かわさき 愛の街」
という川崎市民の歌のメロディーが流れるのですが、
横浜市も同じようにゴミ収集車の音楽があるというのを知りました。
版権の関係があるらしくアニメ中では音楽が流れなかったのですが、後でWebで調べてみると3曲あるらしい
(参考記事))。
テレワーク。早くもなく遅くもなく終了。
Blenderリハビリ。思い出したりする点もあれば、これできるんだと新たな方法を知ったりとか。
GoogleAIで操作方法を聞いても回答が得られるようになったので探す手間が少し減った気も。
とはいえ、Webページや動画は直接知りたい事とは別の事も知れる(セレンディピティ)ので
記憶の幅は広がると思います。GUI操作は文字説明だけだとどういう事なのか分からない場合もあるので。
AM中に起床。
掃除したり洗濯したり。
「ONEPIECE(114)」。一つ大きなネタが回収された感じなのでしょうか。
Copilot Keyboardのキャラクターをデスクトップ表示してますが、クリックすれば
AIチャットが開始されます。そういや、これって絵も描けるんだっけ？と思ったので
「アクア自身を絵に描くことはできますか？」と聞いてみたら自分の説明はできるが
絵は描けないという感じみたい。
それじゃぁと思い EdgeのCopilotの方で「Copilotキャラクタのアクアを絵にしてみて」って注文してみたら、
というのが描かれて、「いや、誰だよ？！」って感じになりました🤣。「Copilotの」は無視されている
感じがしますが、「アクア」と言われるとこういう感じだよねって事なのかしら？
それにしても器用なもんです。
因みに、Googleで「アクア」を画像検索するとトヨタのアクアしか出てきませんでした😓。
これはこれでどうなってんだ？感はあります。
AM中に起床。
ちょろり買い物にお出かけ。
Emacsのmasterブランチをpullしてみたり。
先日、WindowsビルドのGUI Emacsでフレームのスクリーンショット画像
保存する機能がコミットされたのをCygwinでも対応してみたり。ファイル名の変換部分で
コンパイルエラーになるのですが、以前対応した
サムネイル生成のCygwin対応と同じようにすればOKそう。
w32-export-frameというELISP関数が追加されるのですが、こちらの関数はinteractiveではないみたい。
「(w32-export-frame nil "test_export_frame.png" 'png)」のように関数実行すれば一応
フレームのスクリーンショットが保存できるようです。
ただ、ソースコード(src/w32image.c:w32_gdip_export_frame()内)にもコメントが記されているのですが、
フレームサイズよりも一回り大きな領域が保存されるようです。
なんとなく影表示に必要な分まで保存されている感じがします。
あと、BMP画像で保存すると 画像ビュア(IrfanViewとか)によってはウインドウの中が透明に
表示されるようなBMPファイルになっているようです。
余白の件を鑑みますに、やっぱりWindowsの標準機能でスクリーンショットを取った方が良いんじゃないか？
と思わなくはありません。
BMPファイルにExportしたらウインドウの中が透明になる場合がある件。
「GetDeviceCaps (hdc, BITSPIXEL)」でピクセル当たりのビット幅を検査しているのですが、
32と返ってきていました。BITMAPINFOHEADERのbiBitCountにそのまま32をセットしていたのですが、
24に強制すると24bitのBMPになるようだったので、
「header->biBitCount = bits_per_pixel>24 ? 24 : bits_per_pixel;」てな感じに
パッチを当ててみました。
見た目よりも大きなサイズになる件を GoogleAIで聞いてみたところ、
GetWindowRect()ではマウスの反応する領域だったり影描画の部分だったりを含んだサイズが返される
という事のようです。見た目通りのサイズを取得するには DwmGetWindowAttribute() という関数を
使用すれば良いらしい。という訳で対応してみたのですが、サイズについては所望のものになったものの、
座標がなんだか少しずれているようです。見た目合わせでハードコーディング対応したのですが、
そうなんだっけ？とは思ったりも。
因みに DwmSetWindowAttribute()の方は w32fnc.c内で動的ロードして使用しているようだったので、
今回必要な DwmGetWindowAttribute()の方も同じ感じに設定してみました。ただし、Setの方はw32fnc.cは
w32fnc.c内で使用しているのでstatic宣言されているのですが、今回追加するGetの方は
w32image.cで使用するのでexternにする必要がありました。それもあって地味に変更箇所が多くなってます。
スナップショット画像の座標。ハードコーディングしたのですが、ディスプレイ表示の拡大率を変えるとやっぱりダメでした😓。
GetDpiForWindow()でDPIを取得して 96dpi との比で拡大率が求められるのですが、
座標は単純な比では無いようだったので倍率を変えてズレているピクセル数を調べて式を導出してみたところ
「off_x = (GetDpiForWindow(hwnd)*100/96)/25 + 3;」という感じのようです。
そういうものなのか？という疑問は抱かないことにしよう。
という訳で、もう一声直して多分イケた気がします。ただ、GetDpiForWindow()はWindows10の 1607以降じゃないと
使えないようなので、Windows10より古いバージョンのサポートをまだ切っていないように思える
本家では仮に修正可能だとしても適用されないんじゃないかな？という気がします。
やっぱりWindowsの標準機能でスクリーンショットを取った方が良いんじゃないか？と思うのは変わらず。
テレワーク。早めに終了。
タイピングplus。
今日、やっとLv70に到達🥳。Lv69→70に上げるのに経験値が100万くらい必要で、
Lv68→69とは段違いになってました。次のLv71には 2561000 必要らしい😅。
現在のTANEの練習量では1日当たりの経験値は約4500なので、このままであれば えーっと....
569日くらいかかる計算だな....😑。ボチボチやっていきます....
テレワーク。早めに終了。
そういや、さっぱり触っていないBlenderですが、新PCにしたときに
インストールした4.4.3のままだったのですが、
5.0.1が出ているらしいのでインストールしてみたり。でも、使い方を前以上に忘れていて
全然ダメという感じ😓。
Blenderの入門動画を見て少しリハビリ。ほんのちょっとだけ思い出してきたようなそうでもないような。
テレワーク。早めに終了。
Cygwin-3.6.7-1がリリースされている模様
(リリースアナウンス)。
Emacsハングに関連しそうな修正は入っていない感じ。という訳で、
3.6.6と同じくEmacsハング対応にパッチを当ててビルドして
アップデートの準備をしたり。ビルド自体は問題無し。という訳でパッケージインストールしたあと直ぐに
パッチ版に差し替えて、一応Emacsで負荷テストしながら普段使いする感じで。
テレワーク。早めに終了。
プライベートでも本物お仕事でもコマンドラインプログラムを使うことが多いのですが、
たまに慣れていない人の使っている様子を見ていると単純に操作に時間がかかるなぁと感じることがあります。
何気にGoogleで「linuxコマンドの使い方の要領の悪い人」で検索してみると、
「まさにそれな」って感じのAI回答が出てきたので、思わずスクリーンショットを保存してしまいました😅。
「コマンドライン操作に慣れていない」という言い訳も微妙で、様子を見てると、
テキスト編集操作もイマイチだし、タイピング速度もイマイチだし、結局、全体的にうっすらイマイチと
感じなくもありません。
そういえば以前、変換候補の横に出る候補の説明表示ウインドウには
名前が付いていないということを記したのですが、Copilot Keyboardでは「Copilot Answer」と呼んでいるようです。
因みに我が家では「Copilotの回答」と表示されています(前も今も)。
テーマによって違うの？
テレワーク。早めに終了。
BIOSアップデートが来ていたり。前回は2月4日だったので月一回の頻度で来てるな。
こんな頻度で更新する必要があるのだろうか？🤔
BIOSアップデートの都合でWindwsを再起動したのですが、何故か先日起こっていたビルドした実行バイナリを
実行すると/tmpにmat-debug-*.logというファイルが生成される事象が再現しなくなったり。どういうこと？🤔
もしやと思って確認してみたところ、IMEをCopilot Keyboardにしていると、
/tmp(恐らく環境変数TEMPで指定したディレクトリ)に「mat-debug-*.log、*.db、*.db-shm、*.db-wal、*.db.ses」
というファイルが作られるようです。
IMEを MS-IMEに切り替えると前述ファイルが作られることはないみたい。
Windows起動直後は MS-IMEに向いているのですが、その状態で再現確認をしてたので気づいた感じです。
なぜそういうことになるのかは不明。
mat-debug-*.logの *には起動したプログラムのプロセスIDが記されるので、実行ファイルが何らかの仕組みで
自力でファイルを作っているものだと思ってました。てか、実際そのようなもののハズみたいですが。
という訳で遡ってしまいますが、先日のメモに追記しておきました。
コンパイル環境が原因ではないという事が分かったのでのでひとまずヨシとしたもんか。
逆に Copilot Keyboardはまだまだ色々あるなぁ...という感じがします。
Copilot Keyboardのアップデートについて、
Windows Blogs
の方でも記事が投稿されているようです。
AM中に起床。
掃除したり。
ちょろりコーディング。D言語で書いているのですが、/tmpに mat-debug-*.logみたいなファイルが勝手に生成される
実行バイナリになってて邪魔だなぁ？と思ったり。Releaseビルドにすれば良いというAI回答があったのですが、
Visual Studioのビルド構成をReleaseに指定するみたいなのが出てきて、いや、リンカーオプションじゃないのか？
と思ったのですが、リンカーに「/DEBUG:NONE」とかを指定しても状況変わらず。むぅ🤔
これまで気になったことは無かったのですが、今のデスクトップPCにした時にVisual Studioを新規に入れた
のがトリガーになっているかも知れず。今頃気づいたのはデバッグでコンパイル＆実行を繰り返している為、
大量にファイルが生成されているのと時間的についさっき作られているな？というのに気づいたからかも。
EmacsのmasterブランチにWindowsビルドのGUI Emacsでフレームのスクリーンショット画像を撮る
仕組みが追加されるみたい。Windows以外のGUIビルドのEmacsでも使えている機能なのだろうか？
あえて自力で撮れるようにする必要は無いようにも思えるのですが、
表示バグを押さえるのに使えたりするのかもしれません。
AM中に起床。
ちょろりコーディング。
Copilot Keyboardのアップデート内容。MS Storeの説明に記されてました
(参考)。
「一部アプリでクラッシュの修正」というのがありますが、どのような事象だったのだろう？
というのは気になります。
テレワーク。早めに終了。
Copilot Keyboardのアップデートが来ていたの入れてみたり。Windowsの再起動が必要なのは変わらず。
前回から変わった点や新規追加案件、思ったことをメモっておこうと思います。
テレワーク。早めに終了。
ちょろり実験コーディング用の仕込み。
テレワーク。早めに終了。
調べごとをして終了。
テレワーク。早めに終了。
Web巡回して終了。
AM中に起床。
Copilot Keyboard。以前のメモの補足。
長い文章を入力していると、そのうち先頭の方は自動的に変換確定するのですが、その時に一瞬入力フォーカスが
失われてしまうのか、入力を取りこぼしてしまうことがあります。入力しているその瞬間の文字が失われている
場合もあるのですが、変換を行うときに失われる場合もあるようで、おかしな変換結果になっていて
初めて入力文字が消えているのに気づくという感じです。
これが解消されれば ひたすら入力を続けて変換性能を見ることが可能だと思われます。
因みにMS-IMEでは取りこぼしは発生しないようです。
「シン・エヴァンゲリオン劇場版𝄇 TV版」。なんでTBSでの放送なのだろう？とは思ったりも。
番組最後に完全新作シリーズを制作することが発表されましたが
(公式)、それと関係があるのだろうか？
Webで検索してみると 真偽のほどはわかりませんが、劇場公開後は Amazon Prime Videoでの独占配信だった事と、
Amazon Prime Videoと TBSは関係がある事などからTBSでの放送が可能になった....というのがもっともらしい感じがします。
そういや ヱヴァンゲリヲン新劇場版 はインディーズ映画だったのを忘れてた。本来、TV放送局に縛られる必要は
無いのかも知れません。
AM中に起床。
掃除したり。
以前、テーマのカスタマイズメニューで使用している
ボタンのSVG描画が変になっているということを記したのですが、
修正されたようです(修正コミット)。
コミットコメント的には reverts commit となっているので、壊していたということなのか？🤔
それにしても以前にも記したことがありますが、
revertすることが多いなぁとは思います。
AM中に起床。
ちょろり買い物にお出かけ。
Copilot Keyboardを普段使いしてみているのですが、打ち間違えなければ今のところ変換精度は良いかもしれません。
打ち間違ったまま変換してしまうと直せないので、その時はあきらめて変換確定してから
部分修正するしかないのですが、恐らく多くの人はIMEの編集状態で修正することはしていないと思うので、
打ち間違いのあるまま変換して直せなくても問題とは思われないかもしれません
(そして変な変換候補が覚えられてしまう)。
最新バージョンではCtrl-hがバックスペースになったので、一つ前のバージョンの時のように打ち間違いを直すつもりが
Emacs本体にパススルーされて元の文書の方を壊してしまうということが起こらなくなったのが
個人的には都合がよくなったと思うところです。後、IME入力中も「無変換」と「変換」で英数とローマ字を
切り替えられるのが一番良いと思ったところです。むしろMS-IMEの方で「無変換」を押してカタカナに
なってしまうことが、MS-IMEを使用している本物お仕事の方で弊害が出ているかもしれません😓。
以前のメモに記したEmacsで辞書表示(候補の説明表示)できない件については特に調べていません。
当面はCopilot Keyboardのバージョンアップの度に確認してみようと思ってますが、
メモにも記した通り変な事が入り込む余地も無いように思えるので、どうやって調べたもんか？というのはあります。
テレワーク。遅めに終了。
Web巡回して終了。
テレワーク。早めに終了。
調べごとをして終了。
テレワーク。早めに終了。
調べごとをして終了。
テレワーク。気持ち遅めに終了。
Web巡回して終了。
テレワーク。気持ち早めに終了。
Web巡回して終了。
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)
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割以上を覆い尽くしていきます。やがて乾季になり、だんだん水が引き始めると、そこには様々な形の池や水辺が残ります。 ================================================================================
テレワーク。早めに終了。
Emacs31系になる予定のmasterブランチのNEWSに、MS-Windowsでカラーフォントのサポートについて
記されている項目があり、w32-inhibit-dwriteというカスタム変数でカラー表示を無効化できる旨が
記されています。しかし、CygwinでビルドしたEmacsで変数を調べてみてもそんな変数は無いと
エラーするようだった(以前のメモ)ので調べてみたり。
どうやら WINDOWSNTのdefineのみ定義されるようなコードになっていて、
Cygwinビルドの時には定義がスキップされている模様。ちょろっと直して
CygwinビルドのEmacsでも表示切替ができるようになってみたり。
そういやEmacs31はいつリリースする予定なのだろう？ Windowsビルド向けにカラー絵文字の対応が
公式に入ってからもう1年半が経過する(以前のメモ)
のだけれど.....
テレワーク。早めに終了。
調べごとをして終了。
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」となりました。何が変わったのかはよくわからず。
テレワーク。早めに終了。
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のままなので、
サポートをやめたら、表示できないページだらけになってしまう
→そんなブラウザは使われない→ブラウザの方が死ぬ という論法。
テレワーク。早めに終了。
以前のバージョンのMS-IME。
こちらのページの存在を知りました。
「以前のバージョンのMiccrosoft IME」の設定には、英字や数字を常に半角に変換する設定があるらしい。
括弧についても設定できるようなので、かなり細かくどのように変換するかを指定できるみたい。
これをそのまま移植した上で 変換効率だけを上げてくれればよいのにと思わなくもありません。
Emacsの「C-u」で数値を入れたのち、文字やコマンドを入力すると数値の数だけ文字入力やコマンド実行が
行われます。viで実行したい回数を値で入れてからコマンド実行するのに似たことができます。
なのですが、なぜかC-y(yank)は期待通りの動作が行われないなぁ？と思ったり。なんでだ？🤔
一旦キーボードマクロでyankを1回実行したものを記録して、C-uで回数を入力したのちマクロ実行すると、
見かけ上指定回数だけyankを実行したようには振る舞うようです。
正確に多くの回数実行しなくてはならない場合には良いかもしれませんが、
10回以下なら数えながらC-yを押してしまうな😅
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の変換候補ウィンドウ（または予測候補ウィンドウ）に付随する候補の説明表示（ツールチップ）と呼ばれます。」
だそうな。要するに名前は無いらしい。言語化するのに不便です。
AM中に起床。
掃除したり。
Webを散策していたら、Copilot Keyboardのバージョンアップが出ているらしいというのを知り
確認してみたら確かに来ていたので入れてみたり。Windowsの再起動が必要なのは変わらずです。
さておき、アップデートを知った
記事
によると、ショートカットが MS-IMEと同じ感じになったみたい。
因みに Japan Windows Blog の記事は
こちら。
また、特定のアプリでスローダウンする現象(個人的に確認したものではxyzzyはスローダウンしてました)が解消
されているという事だったので、Emacsで長い文章を入力してどうなるか確認してみたのですが、
やっぱりスローダウンするようです。
前回からの違いや、思ったことをメモっておこうと思います。
テレワーク。早めに終了。
調べごとをして終了。
テレワーク。気持ち早めに終了。
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は使ったこと無いのでわかりませんけど。
テレワーク。気持ち早めに終了。
BIOSアップデートが来てたので入れたり。前回からの周期がやっぱり
短い気がします。旧PCではこんなにBIOSアップデートした記憶は無いのだけど。
テレワーク。早くもなく遅くもなく終了。
「Emacsの雑記」を更新しました。
「半角/全角キー」によるIME状態切り替えの設定対応(以前のメモ)と、
wrapped_convertでJXL画像が表示できなくなっている件の対応(以前のメモ)について
更新しました。wrapped_convertについては、まだmagickコマンドのみにはしていないので、これまでの設定通りで
JXL画像表示に関する不具合のみが修正されるつもりです。ご参考まで。
テレワーク。早めに終了。
そういえば矩形選択した位置に文字列を挿入する場合、Emacsだと矩形で1カラム×複数行選択しておいて、
「string-rectangle(C-x r t)」で文字列挿入できます。
vimでも同じ感じでできるだろうと思って C-vで縦に矩形選択した後、「i」で挿入モードにしたつもりですが反応無し。
「I(Shift+i)」じゃないとダメみたいですが、単純に「なんで？」とは思ったりも。
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]