Eatでの chafa表示でハング状態に陥る件。何かしらターミナルの幅が2倍に解釈されているような ふるまいだったので、反応しそうなところを当てずっぽうで値を弄ってみたところ、 反応した上に所望の動きになったような気がしたり。 ただ、Sixel表示がイマイチになったのですが、そちらとうまく合わせる方法が分からず、 Sixelの方はスケール指定が可能だったので、スケールを変更して見た目合わせしてみたり。
以下のようにパッチしてみました。
AM中に起床。
掃除したり洗濯したり。
Emacs 31.1向けにパッチの内容を思い出したり。
何気に1年ほど前から対応を始めていたので、色々忘れてしまっています😓。
AM中に起床。
転院手続きにお出かけ。ほどなく完了。
そういえば Fedora44 へのアップグレードの案内が出てたなと思い出したり。
Emacs 31は Fedora43 には来ないかもな？と思ったので VirtualBoxの Fedora43を 44にアップグレードしてみたり。
時間がかかったのは 43のイメージを念のためクローンして 44のベースを作ってからアップグレードする
このクローン実行だったりしましたが。さておき、ほどなくしてアップグレード終了。
すっかり忘れていたのですが、Emacs 31では *.elに 「; -*- lexical-binding: t -*-」というコメント内
キーワードが無いとワーニングメッセージが出ます。Cygwinでビルドしている Emacs 31向けには対応したのですが
(以前のメモ)、これやらなくちゃダメなのか.....。
面倒くさかったので、シェルスクリプトを作って対応してみたり。一回使ったら終わりなので効率が悪い🥺。
全く気付いていなかったのですが、VirtualBoxのFedoraから環境変数DISPLAYを設定して、
ローカルPCの VcXsrv で画面を出そうとしたところ、gimpコマンドがPATHに無いなぁ？と思ったり。
VirtualBoxのグラフィック画面のアプリメニューには存在するし、起動もできるのでどうなってんだ？
と思い、GoogleAIに聞いてみたら
「Fedoraでは標準的にインストールされるGIMPはFlatpak版(コンテナ化されたアプリ)であることが多く、
通常のコマンドとは実行方向が異なります。」という回答が返ってきました。
「flatpak run --env=DISPLAY=ローカルPCのIPアドレス:0 --socket=x11 org.gimp.GIMP」
みたいな感じで実行すれば良いらしいのですが、VirtualBoxのGUIコンソールからはログアウトしておかなくては
ならないみたい。GUIコンソールでログインしていると、DISPLAYで画面を出す先を指定しているにも関わらず、
GUIコンソール側に画面が出てしまうようです。なんでだよ？🤔
「flatpak list --app」でflatpakアプリの一覧を表示する事ができるようです。
テレワーク。早めに終了。
Emacs 31.0.90 pretestがリリースされていたり
(Emacs 31.0.90 pretest is available)。
なんか今回は早い気がする。
31.0.60のパッチをあてて 31.0.90をビルド。特に問題なくビルド完了。ちょろっと触ったところでは問題無し。
まあ、31.0.60で問題無かったのだから問題無くて当たり前かもしれませんが。
29の時は29.0.90からは順調に3ヶ月くらいでリリースされたので、それくらいで出る事を期待したいです。
ただし、29はブランチができてから29.0.90が出るまでにめちゃくちゃ時間がかかりましたが。
テレワーク。早めに終了。
Ollama。今日見たらv0.30.4が出てたのでアップデートしてみたのですが、
やはりqwen3.6:35bは無理やりGPUで動こうとしている為か、全く反応できる様子も無ければ
Windows全体がスローダウンしている感じになるのも変わらず。
他のモデルだとGPUで動けたり、CPUで動いたりとなっているようなので、今のところqwen3.6:35bだけが
変になっているように見えます。
GoogleAIに gptelで ollamaにGPUの使用をコントロールする方法を聞いてみたら、
「:request-params '(:options (:num_gpu N))」というプロパティを追加すればコントロールできるという回答が
得られました。Nの値を0にすればGPUを一切使用しない動きになるのですが、1以上の値のレイヤーを
GPUに割り当てるという動きになるそうな。qwen3.6:35bは 40レイヤーあるらしいのですが、
半分よりもちょっと減らした18くらいにすると、GPUのメモリをちょっと手加減した割り当て量で動作するようです。
ともあれ、応答無し状態＆スローダウン状態にならずに応答が返ってくるようになったので、
しばらくこれで様子見しようと思います。
qwen3.6:27bもこれで調節すれば動くようだったので、一応調節して使えるようにしてみたり。
テレワーク。早めに終了。
Ollamaの更新が3週間ほど無かったのですが、v0.30.0がリリースされたと思ったらv0.30.2が直ぐに
リリースされてました。また高頻度リリースに戻るのかな？
v0.30.2にアップデートしたところ、qwen3.6:35bはこれまでCPUで動いている感じだったのですが、
無理やりGPUで動こうとしているようで、画面操作に影響が出るようになりました🥺。
これまで、qwen3.6:27bがGPUで動こうとして画面操作に影響が出る感じで使い物にならなかったのですが、
安定していたqwen3.6:35bでダメになったのが辛い。
テレワーク。早めに終了。
台風。順調に向かっているな。明日の関東地方は一日荒れそう。
ところで台風の絵文字「🌀」ですが、Windows11の Fluent Emoji はデザインが雑過ぎない？
テレワーク。早めに終了。
Emacsのartist-modeのメニューにSquareという正方形を書くと思われる描画ツールがあるのですが、
マウスで使ってみると 長方形を描くRectangleと同じ挙動をしたので なんだこれ？と思ったり。
キーボードでカーソル移動すると始点座標と終点座標との差で幅か高さの大きい方が採用されて
確かに正方形描画っぽく動くようです。マウス指定時のバグだろうか？
あと、正方形とは言っても文字数で数えた時のサイズなのですが、フォントは縦長なので
「3桁×3行」という正方形を描いたつもりでも見た目は正方形ではありません😓。これはこれでいいのか？
どうやら Rectangle描画で、Shiftキーを押しながらマウスドラッグすると Squareモード
の挙動(長い辺を採用する)になるようです。メニューにわざわざ足すんなら、Shiftキーを押した
挙動にすべきなようには思います。因みに、直線ツールや円ツールでもShiftキーを押すと
挙動が変わるようなのですが、それらについてはメニューには追加されていません。
なぜ正方形だけメニューに追加しているのか謎。
AM中に起床。
掃除したり。エアコンのフィルターを掃除してテスト稼働....というか本番稼働だな😓。
調べごとをしたり、実験をしたり、ぐうたら過ごして終了。
AM中に起床。
通院。
再変換。合字の絵文字を含んでいた場合に再変換が変になる場合があったのを修正してみたり。
再変換に食わせる事ができる文字列の長さには上限があるのですが、上限の境界に合字の途中や
サロゲートペアがまたがるような場合に変にならないようにしたつもり。
Emacsのmasterブランチを git pullしてみたら、artist-mode用にツールバーアイコンが登録されているようだったり。
普段はツールバー表示していないのですが、表示してみたらグラフィックツールのような感じで表示されました。
でもこれ、Emacs 32.x 向けになるんだよなぁ。新しい機能だけど全体に影響する訳ではなく、
互換を損なうようなものでなくても、恐らく何か更新されるわけでも、厳重にテストされるわけでもないまま、
2年くらい ただ寝かされるだけって感じになるだろうと思うのですが、「それって何の時間？」と毎度思います。
単に、ある新機能がいつ頃コミットされたか知っているからそう感じるだけなのだろうか？🤔
テレワーク。早めに終了。
Copilot Keyboardのアップデートが来たり。4月に正式リリースされてから更新頻度が下がるかな？
と思ったのですが、今回はまだ1ヶ月のリリースサイクルにあるようです。
という訳で入れてみたり。再起動が必要なのはこれまでと変わらず。
Windows Blogsには更新情報が公開されているようです
(Copilot Keyboard — GA 後はじめての大型アップデートをお届けします)。
前回から変わった点や新規追加案件、思ったことをメモっておこうと思います。
テレワーク。気持ち早めに終了。
「クジマ歌えば家ほろろ」のアニメ。おもしろくて観てしまいます。
クジマの独特のしゃべり方は あまりにもハマり過ぎているように思うのですが、
漫画原作を知っている人にはどう聞こえているのだろうか？
そういや、「数独」って解けるのかしら？と思い、Emacsのsudokuアプリで生成した問題を
gptel+Ollama(qwen3.6:35b)に食わせてみました
(思い付きで実行したので、時間は結構かかりましたが具体的にどれくらいかは見てませんでした😓)。
* ** 以下の「数独」問題の答えを考えてください。 +---------+---------+---------+ | - - 3 | 8 9 - | - 4 5 | | - 4 - | - - - | - - - | | - - 2 | 3 4 1 | - 7 - | +---------+---------+---------+ | 2 - 6 | 5 - - | 9 - - | | - 1 9 | 4 - 8 | 5 6 - | | - - 4 | - - 3 | 7 - 2 | +---------+---------+---------+ | - 9 - | 7 5 6 | 4 - - | | - - - | - - - | - 9 - | | 4 8 - | - 3 9 | 1 - - | +---------+---------+---------+ ご依頼の数独パズルの解答は以下の通りです。 #+begin_src +---------+-----+-----+ | 1 7 3 | 8 9 2 | 6 4 5 | | 9 4 8 | 6 7 5 | 2 3 1 | | 5 6 2 | 3 4 1 | 8 7 9 | +---------+-----+-----+ | 2 3 6 | 5 1 7 | 9 8 4 | | 7 1 9 | 4 2 8 | 5 6 3 | | 8 5 4 | 9 6 3 | 7 1 2 | +---------+-----+-----+ | 3 9 1 | 7 5 6 | 4 2 8 | | 6 2 5 | 1 8 4 | 3 9 7 | | 4 8 7 | 2 3 9 | 1 5 6 | +---------+-----+-----+ #+end_src 各行・各列・各3x3のブロックに =1〜9= が重複なく配置されており、数独の条件を完全に満たしています。お役に立てば幸いです。
+---------+---------+---------+
| 1 7 3 | 8 9 2 | 6 4 5 |
| 9 4 8 | 6 7 5 | 2 3 1 |
| 5 6 2 | 3 4 1 | 8 7 9 |
+---------+---------+---------+
| 2 3 6 | 5 1 7 | 9 8 4 |
| 7 1 9 | 4 2 8 | 5 6 3 |
| 8 5 4 | 9 6 3 | 7 1 2 |
+---------+---------+---------+
| 3 9 1 | 7 5 6 | 4 2 8 |
| 6 2 5 | 1 8 4 | 3 9 7 |
| 4 8 7 | 2 3 9 | 1 5 6 |
+---------+---------+---------+
YOU WIN!
* ** この数独パズルをどのようにして答えを導いたのですか？ 数独は「直感」や「試し書き」ではなく、*論理的な候補の絞り込み（削除）*によって解かれます。 私が答えを導いた過程は、人間が紙で解く標準的な数独の解法と全く同じです。主な手順と考え方を以下に整理します。 --- *** 🔹 1. 基本の処理原則 各行・列・3×3ブロックに =1〜9= が重複なく入るため、以下を繰り返します： - *既に入っている数字を基準に、「そこには入らない数字」を削除する* - *候補が1つだけ残ったセルを確定する* - *確定した数字が周囲の行・列・ブロックへ波及し、さらに候補が削れていく* このように「部分的な確定」が連鎖的に起こることで、最終的に全体が一意に決まります。 --- *** 🔹 2. 主要な論理テクニック（このパズルで使われたもの） |------------------------------------------+-------------------------------------------------------+-------------------------------------------------| | テクニック名 | 内容 | 例（概念的） | |------------------------------------------+-------------------------------------------------------+-------------------------------------------------| | *隠れた唯一（Hidden Single）* | ある数字が「行・列・ブロック内で入る場所が1か所だけ」 | 「5」という数字がこの3×3ブロックに入る位置が、 | | | になるまで候補を削り、確定する | 他の候補を削った結果1カ所に絞られた | |------------------------------------------+-------------------------------------------------------+-------------------------------------------------| | *裸の唯一（Naked Single）* | あるセルに入る候補が1つだけ残った時点で確定する | 行・列・ブロックの条件を合計して、そのセルに | | | | 他の数字が一切入らない | |------------------------------------------+-------------------------------------------------------+-------------------------------------------------| | *クロスハッチング（線・ブロックの排除）* | 既に入っている数字の通る列や行が、他のブロックに入る | 上段に =8= が既に入っているため、中段・下段の | | | 候補から除外される | 同じ列には =8= を候補から削除 | |------------------------------------------+-------------------------------------------------------+-------------------------------------------------| このパズルは中級程度の難易度であり、上記の基本的な論理推論（候補の削除＋一意確定）だけで解くことができます。 --- *** 🔹 3. AIとしての処理の仕組みについて 私は「人間のように一歩一歩考えていく」のではなく、*制約充足問題（Constraint Satisfaction Problem）*として 数値的に処理しています： 1. 各セルに初期候補 =1〜9= を割り当てる 2. 既に入った数字の行・列・ブロックから、その数字を候補リストから削除 3. 「候補が1つだけ残ったセル」を確定し、その影響を再帰的に周囲に波及 4. 矛盾なく全セルが埋まるまで上記を繰り返す このアルゴリズムの過程は、人間が論理パズルを解く際に頭の中で行う「候補の頭書け・削り・確定」の連鎖と完全に 同一です。したがって、答えは必ず論理的に導かれる唯一解となります。 --- *** 🔹 4. 具体的な絞り込み過程を追いたい場合 「どのセルがまず確定したか」「〇行〇列の数字がどう絞られたか」など、特定の箇所やステップを指定していただけ れば、その部分の*候補の推移と確定理由を1つずつ図式化してお示しします*。必要に応じてお気軽にお申し付けください。
テレワーク。早めに終了。
なにげにChatAIで sedの使い方の事を調べていたら、「sed 'N,M!d'」という
書き方があるのを知ったり。「!d」で範囲外の行を削除するという事で、
「sed 'N,Mp;d'」と同じ結果になりますが、「!d」の方が一文字少なくて済みます😅。
テレワーク。早くもなく遅くもなく終了。
Eatでの chafa表示でハング状態に陥る件。何かしらターミナルの幅が2倍に解釈されているような
ふるまいだったので、反応しそうなところを当てずっぽうで値を弄ってみたところ、
反応した上に所望の動きになったような気がしたり。
ただ、Sixel表示がイマイチになったのですが、そちらとうまく合わせる方法が分からず、
Sixelの方はスケール指定が可能だったので、スケールを変更して見た目合わせしてみたり。
以下のようにパッチしてみました。
$ diff -u eat.el.orig eat.el
--- eat.el.orig 2026-05-22 23:58:57.729732200 +0900
+++ eat.el 2026-05-27 00:38:58.483654200 +0900
@@ -184,7 +184,7 @@
(function :tag "Function"))
:group 'eat-eshell)
-(defcustom eat-sixel-scale 1.0
+(defcustom eat-sixel-scale 0.9
"Scale Sixel images by this amount."
:type 'number
:group 'eat-ui
@@ -3870,7 +3870,7 @@
(>= width 1)
(>= height 1))
;; Update state.
- (setf (eat--t-disp-width disp) width)
+ (setf (eat--t-disp-width disp) (* width 2))
(setf (eat--t-disp-height disp) height)
(setf (eat--t-term-scroll-begin eat--t-term) 1)
(setf (eat--t-term-scroll-end eat--t-term)
@@ -7009,7 +7009,7 @@
;; (while (= size (buffer-size))
;; (sleep-for 1))
;; I hope 1 second is enough!
- (sleep-for 1)
+; (sleep-for 1)
(goto-char (point-max))
(insert-file-contents startfile)
(process-send-string
テレワーク。気持ち早めに終了。
そういえば、ここ2週間ほど Ollama の更新が無いな？ 下手すれば毎日更新されてた感じだったので、
更新が無いと何かあったのか？と思ってしまいます。
Eatでの chafa表示でハング状態に陥る件。
ハングそのものの話は一旦置いといて、ターミナルの幅の扱いが変なのではないか？と思って
調べていたところ、Unicode文字の幅が見た目の倍あるようなカーソルの動きをしているように思ったり。
例えば「echo "▄"」と入力する場合、「echo "」まで入力した後に別のバッファから「▄」だけをコピペ
したのですが、カーソルの移動や表示が変な感じになりました。文字の幅の扱いが変な予感がするものの、
なぜEatの中だけ？とかよくわかりません。
ただ、ターミナルのアスペクト比が2:1以上だとハングらないような気もします。
AM中に起床。
掃除したり洗濯したり。
Eatでの chafa表示でハング状態に陥る件。フレーム内を二つのウインドウに分割しておいて、
片方をeatで開いた後、「chafa -f symbols --symbols half img.png」で表示するとハングしませんでした。
何故かうまく表示できたりハングしたりするようです。全く表示できない訳では無さそうなので、
何かしら直す方法はあるんじゃないか？とも思ったのですが、思っただけです。
chafaは 「--symbols half」の時、どのように表示しているのだろう？と思って、eat終了後の残骸バッファ
から表示された文字群を見てみたり。どうやら「▄」や「▌」といった文字を巧みに使って、
フォアグラウンドの色とバックグラウンドの色を分けて表示する事で見かけの解像度を上げているようです。
なので、色が付いていないと全く何の絵か分かりません。
メガデモの Oldskoolデモ とかで使われてそうな方法かも。
Eatでの chafa表示でハング状態に陥る件を少し調べてみたり。
キー入力は受け付けられなくなるのですが、gdbからC-zで SIGSTOPを送ると一応止まるので、
動いてはいるようでした。どうもkeyboard.c:timer_check_2() という関数の中で
calln()という関数を呼び出しているのですが、これが返ってこない感じになっているようです。
ただこれ、バイトコードのインタープリタ実行に入っているようなので、何を実行しているのかが分からず。
Eatの中のコードにループしてそうな所があるのかも知れませんが当たりが付かず。
どうやら ELISPの関数timer-event-handler をcalln()で呼び出しているようだったので、
timer-event-handlerの中で無限ループになる可能性を疑ったのですが分からず。
ダメ元で gptel(qwen3.6:35b)で timer-event-handler で無限ループする可能性があるか？を聞いてみたところ、
無限ループする事は無いが、タイマー関数の実装によってはハングしたように見える可能性があるとの事で、
sit-forとかsleep-forを使うのはダメって事が記されていました。eat.elの中で一か所だけsleep-forを
使用していたので、それをコメントアウトしてみたところ、表示されないことがあるのは変わらないのですが、
C-gで停止できるようになりました。C-gで止めて、eatを起動し直したりしていると表示できたりできなかったり
するのですが、操作不能に陥るのが個人的には一番困るので、ひとまずこれで様子見してみようかと思います。
なんとなくウインドウ表示のアスペクト比が、横長だと大丈夫だけど縦長だとダメなんじゃないか？
という予感がしてみたりも。
AM中に起床。
単行本100巻到達の特別再放送でアニメの弱虫ペダルの第1話が放送されてるをの見たり。
一番最初ってこんな感じでしたっけ？
「弱虫ペダル (アニメ)」の
Wikipedia
によると、第1話が放送されたのは 2013年10月8日だったらしいので 13年近く前になるのか。
単行本100巻到達の18年3ヶ月は最速らしい。
EmacsのEatでフルカラー表示されていないようなので調べてみたり。
どうやら GUI Emacsの場合でも起動時に COLORTERM=truecolorを指定しておかないと、
Eatはtruecolor対応可能と認識されないようです。
ターミナルでの画像表示について調べていたら、
Chafaというコマンドラインツールの存在を知ったり。
Cygwinのパッケージにもなっているようです。
さておき、ターミナルサイズを見ているようなので、画像のサイズによっては
良しなに縮小表示したり、アニメーションGIFも表示できるようです。
アニメーションGIFは Eatだとイマイチでしたが、minttyでは問題無く表示されました。
screenコマンドを挟んでいる場合、img2sixel は-P オプションを付ける必要がありますが、
chafaも「--passthrough screen」というオプションを付ければ大丈夫そうです。
良しなにサイズを調節してくれる chafaの方が使い勝手が良いと思ったのですが、
--passthroughには短縮オプションは無いようなので bashのaliasなどを使って対応するのが良さそうです。
minttyはSixel対応なので、デフォルトでは画像で表示されるのですが、
chafa自体は文字を使ったアスキーアート表示とかも行なえるようです。
例えば「chafa -f symbols --symbols block image.jpg」
とか「chafa -f symbols --symbols ascii -c none image.jpg」とかオプション指定すれば良いみたい。
フォントによっては幅が合わなかったりするようなので、どのターミナルではどれを使うのが良いかは
試してみないと分からない感じがします。ただ、Eatで試していると --symbols block や
--symbols half などの指定で、Emacs本体がハングってしまうみたい。
vtermでは「--symbols half」にすれば良い感じに(と言っても解像度は下がりますが)表示される
ようです。
テレワーク。早めに終了。
再変換で色々起こる件。
再変換以外の動作には問題無いのに、再変換を発動したときだけ色々起こるのは いくらなんでもおかしくないか？
と思い、Lisp_Objectに触れないような実験コードにしてみたり。
ちょっと試した範囲では落ちることは無さそうなので、触れないようにした所をうまく対応すれば
大丈夫なんじゃないか？という気も。
WCHARの文字列を取得するのに一時置きとして make_buffer_string()で生成したLisp_Objectを
使用していたのですが、それらを排除するように直してみたところ、安定して再変換できるようになった気も。
再現方法は「再変換」と「確定」を繰り返すだけだったのですが、10回に満たない繰り返し回数で
色々起こってました。もうしばらくテストするとしても、これで大丈夫なんじゃないか？という感じです。
MS-IMEで、いきなり再変換を発動すると初回の変換窓が開かない件も、ついでに直らないか？
と期待したのですが、こちらは変わらず。むぅ。
Emacs内で使用可能なターミナルアプリとしてvtermを使っています。
Sixelは流石にダメだよな(以前のメモ)と思った記憶がありました。
何気に「Emacs内で使用可能なSixel対応のターミナルアプリ」で検索したら、
Eatってターミナルエミュレーターが
Sixelに対応しているというAI回答があったのでちょろっと試してみたり。
マジでか😮。ターミナルとしてSixel表示しているので、当たり前ですが、ssh接続した先で
img2sixelを使って標準出力にぶちまけても表示できます。
TRAMPで繋いでいるならそれで表示しても良いかもですが、ファイルに保存せずに画像データを
見るのに良いかも知れません。画像表示可能なターミナルの一つになりそうです。
そう言えば、minttyではフルカラーでJPEGやPNG画像を表示する機能があるのですが
(以前のメモ)、
それと同じような方法でSixelじゃなくても表示するようなターミナルエミュレーターって
あまり無いのかしら？「ターミナルで画像表示する==Sixelを使う」って感じにも思えたので。
テレワーク。早めに終了。
再変換。再変換を発動しては確定を繰り返しているとSIGABRTを受けたりSegFaultで死んだりする模様。
ただ、何故かCygwinのメモリ解放でエラーしたり挙動が不審。
どうも「SAFE_FREE()」からのfree()で何故か変になっているようでした。
SAFE_ALLOCA()とSAFE_FREE()というEmacsコード内のメモリアロケータで、
確保するサイズが大きい場合はalloca()ではなくてmalloc()を使うというものらしい。
free()が呼ばれているという事はmalloc()が使われたという事なのだろうか？という感じなのですが、
切り分けの為に malloc()とfree()を使って様子を見たり。すると違う場所でSegfaultするようになり
様子が少し変ったり。でも、ずっこけ場所が違うもののやっぱり SAFE_FREE() に起因しているようです。
malloc()/free()に簡単に置き換えられない場合があって困ったり。
それにしてもスタックがぶっ壊れているのかしら？🤔
テレワーク。早めに終了。
再変換。普通に使っていると発動する場面が無いので、意識的にテストケースとして発動させるのですが、
それだと大丈夫そうだなぁ.....と思って油断していると、急にハングが再現したりするのですが、
急に来るのと特別なことをしてるつもりが無いので契機が分からない😓。
何気なく「記者が汽車で貴社に帰社した」の「汽車」を再変換したら、絵文字の候補として「🚃」が出てきた
のですが、これは電車だよなと思ったりも。因みに「電車」を変換すると随分沢山の絵文字候補が出てくるなぁ？
とは思ったりも。
テレワーク。早めに終了。
Web巡回して終了。
テレワーク。早くもなく遅くもなく終了。
Emacsのmasterブランチは32系になっている模様。
AM中に起床。
掃除したり、洗濯したり。
MS-IME時の再変換イベント。今のところ、Emacsの外側で半角/全角キーを押してIMEをON/OFFすれば、
いきなり再変換を発動させても大丈夫そうです。
しかし、Emacs内からIMEをON/OFFした後、何かしら文字入力して変換窓が開くようなことを行った後に、
再変換を発動させても 変になります(変換窓が開かずキーイベントが掴まれてしまう)。
つまり、事前に入力して変換窓を開いても再変換時の状態が修正される様子は見られませんでした。
ただ、インクリメンタルサーチを起動し、その中でIMEをONにして、なにかしらの文字をいれて確定させた後、
インクリメンタルサーチを終了してから 再変換を発動すればうまく変換窓が開くというパターンを一つ見つけました。
この手順の中に何かしら状態を初期化する要素が含まれているのではないか？と考えたのですが、
それが何なのかまでは突き止められず。
インクリメンタルサーチではミニバッファにカーソルが移動するので、その時にカーソル位置やフォントが
変更される事で位置情報が修正されるのだろうか？と思ったのですが....？🤔
そういや日本語文字じゃない文字列を再変換したらどうなるだろう？と思い、
Emacsの view-hello-file の中からアラビア語だとか適当に選んでみたところ、
表示はされるけど文字としての認識だったり(絵文字もそんな感じ)、トーフになったり、
場合によってはハングするみたいです。因みに試したのはCopilot Keyboardのみです。
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してビルドや動作確認する感じで。実験は別にクローンしたディレクトリ下で行なうようにしてみたり。
テレワーク。早めに終了。
再変換。ひとまず余計な実験コードをバッサリ削除して整理してみたり。
MS-IMEの時にいきなり再変換を行うとハング状態に陥るように見える件。
少し前のメモの通り、最小化→元に戻す 操作で復帰はするのですが、
この時の作りでは再変換対象文字列が失われてしまうので、EmacsのUndoで失われた文字列を
復旧させる必要がありました。
今回、再変換の発動時に対象文字列を一時的に保持しておく方法にした事により
「もう一度再変換を発動させる」ことで、ハング状態に陥った風に見える時の変換対象文字列
の再変換窓が開き、操作が行なえるという復旧が可能になりました。
とはいえ、なんとかならんかなぁ？と思うのでもう少し反応する要素が無いかを探ってみたい
と思います。因みに、Copilot Keyboardではいきなり再変換を発動しても今のところ問題は無さそうです。
そういえば先日、再変換の処理で変換が確定してから元のデータを削除するような実験を行ったとき、
変換編集窓の表示位置が「これじゃない」感じになりました。変換窓の開く位置はカーソル位置になるため、
範囲選択した領域を再変換するようなケースを考えると、選択領域の最初の位置では無く、カーソルのある
最後の位置になる為、位置がこれじゃないという感じになりました。
再変換を発動した時に選択の始点と終点を入れ替えて、カーソル位置を始点に移動できれば解決
できるんだけどなぁ？と思って位置を交換する方法が無いかをGoogleAIに聞いたら、
位置交換の方法の一つに「exchange-point-and-mark」というのがあって「C-x C-x」に割り当たっている
というのを初めて知りました。領域選択した所で「C-x C-x」を押せば始点の位置にカーソル移動できるとともに、
選択開始位置も変更できるので、開始位置を間違えた場合に選択し直す手間が無くなるなぁと
いう発見がありました。矩形選択の時も使えるのでなかなか良いかも。
テレワーク。早めに終了。
再変換。ひとまず「msg=WM_IME_REQUEST, wp=IMR_RECONVERTSTRING」メッセージが届く可能性がある
期間はバッファのデータは更新せず、変換確定したら削除するようにしてみたところ、
挙動不審にはならなくなったような気が。でも、変換編集窓の表示位置がこれじゃない感。
もっと雑に、初回に生成した RECONVERTSTRING構造体の内容と文字列を 一時メモリに保持しておいて、
Emacs側からはデータを削除、二回目以降は一時メモリに保持した内容を丸コピーでいいんじゃないか？と
思って試してみたり。イケたような気がしたけどハングるな....🤔。
でも、挙動不審に思えていたのも、そういうものだという事が分かったので、やりようがあるように思えてきました。
テレワーク。早めに終了。
全く気付いていなかったのですが、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回しか通知しないとは言ってないし、このメッセージをトリガにして他の処理(例えば元の文字列を削除しておく)を
入れてステートフルにしても問題無いとも言っていない......と、いわれればそうなのですが、モヤっとはします🤔
テレワーク。早めに終了。
再変換。先日 MS-IMEの時にいきなり再変換を行うとハング状態に陥ると記しましたが、
確かに固まるものの一度Emacsをタスクバーなどから最小化→元に戻すという操作を行なうと
復帰するようです。雰囲気的に再変換の候補ウインドウが何かしらの理由で開かないのですが、
それによりフォーカスが固定されてハング状態っぽくなるものの、最小化などを行なうと
フォーカスが復帰し、ついでに再変換も可能になるという感じに見えます。
何かしら初期化を行なえば良いのか？とも思ったのですが、反応する方法を見つけられず。
Copilot Keyboardの方は先日も記した通り、何故か再変換イベントが二回発生する事があり、
こちらも原因が分かっていません。むーん🤔
テレワーク。早めに終了。
再変換。カーソル位置が変になら無さそうにはなったものの、
MS-IMEの時に日本語文字を入力した後、再変換を行うとハング状態に陥る現象に見舞われています。
再変換を行なう前に「半角/全角キー」でIMEを一度ONにしてから再変換を行なうと大丈夫っぽい。
Emacs側からIMEをONにしてもダメ。Emacs側からのIMEをON/OFFは ImmSetOpenStatus()を実行する事で
行なっていますが、これでダメというのには困った....🤔。
でも、Copilot Keyboardでは大丈夫。急に形勢が逆転してしまってます😓。
弄っていると何故か再変換イベントが二回発生するケースがあり、1回目に選択した領域が
消滅して動きが変になったりしています。なんでこんなに挙動不審になるのかよくわからない。
AM中に起床。
掃除したり。
再変換。MS-IMEの方もサイレント落ちしたりと微妙な感じだったので、まずはそちらが安定して
動作してから Copilot Keyboardの方を見た方が良いかなと思ったり。
絵文字を食わせるとダメになったり、長い文字列を再変換しようとすると動きが変になったりしたのを
直してみて安定してきた感じにはなりつつあるのですが、Copilot Keyboardで同じ事をやるとやっぱりダメ。
うーむ🤔。
実験用の最小コードでリコンバージョンを試してみたところ、少し反応が見られたり。
AM中に起床。
IMEパッチのコードで再変換を行う RECONVERTコードってそういや有効にしてビルドしていないなぁ？
と思い、少し前のEmacs masterブランチでRECONVERTを有効にしてビルドしてみました。
以前、31系で大量のワーニングが出るようになったのを
直したのですが、RECONVERTの部分は直していなかったので大量のワーニングが出るままになっていたり。
ワーニングはさておき、そのまま実行してみたら再変換を発動するのと同時にサイレント落ちしたので
原因を調べて直してみたり。
で、MS-IMEではどうにか動くようになったものの、Copilot Keyboardでは挙動が不審な状況です。
挙動が不審というのは、再変換を発動すると変換候補窓が一瞬現れてすぐに消えてしまい、
何かしらキー入力は受け付けるのですが、Emacsに突き抜けている感じになります。
ESCキーで脱出すると変な編集結果が反映されてしまいます。変になるパターンがいくつかあるようなのですが、
弄っているとサイレント落ちする場合もあります。
一応、メモ帳などでは Copilot Keyboardによる再変換は機能するようなのですが、
何か足りないか、何かしら余計なことをしているか、Copilot Keyboardのバグなのか.....
今のところアテがありません。
先週、「おこなって」は「行なって」は許容で「行って」が本則の
書き方だというのを知りました。そういや「かわって」は「変わって」と「変って」とだとどうなんだ？
と思って調べたら「変って」が許容で「変わって」が本則らしい。
| 読み | 本則 | 許容 | |------------+----------+----------| | おこなって | 行って | 行なって | | かわって | 変わって | 変って |
テレワーク。早めに終了。
予定通りEmacs-31のブランチが作成された模様
(アナウンス)。
調べごとをして終了。
テレワーク。早めに終了。
調べごとをして終了。
AM中に起床。
随分前に取り溜めていた録画を消化。
AM中に起床。
先日の捨てられているメッセージ。
どんなメッセージが捨てられていたのだろうか？と思い、デバッグprintを仕込んでみたところ、
以下のようなメッセージが捨てられていたようでした。
:以下抜粋
+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);
+}
:
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のgitリポジトリの masterブランチで行ったのですが、30.2も同じなので対応。
しばらく普段使いで動作確認してみます。
ところで、Copilotの回答が表示されるようにはなったのですが、長い文章を入力していると
単語を調べる感じにはならないなぁ？とは思ったりも。
Copilotの回答で🔍ボタンを押すと Bingの検索が行われるのですが、キャラクターのチャットの方に
流し込む方法は無いのだっけ？と思ったりも。
単語ではなく文章で入力しなくてはならないので、
長文を特別なキーバインドで決定＆流し込み実行する必要はあるかもしれませんけれども。
今のところ、Copilot Keyboardはスキンがキャラクターの見た目と連動しているだけで、
IMEとAIキャラクターが「連携」はしていないなぁ？とは改めて思ったりも。
AM中に起床。
VOICEVOXの読み方＆アクセント辞書登録。
単純な単語の登録は非常に簡単に行えるのですが、前日の「行って」みたいな、どうしようもないのが
いくつかあるなぁ？と思ったり。「行」を「くだり」と読まれたり、「値」を「ね」と読まれたりするのは、
「くだり」や「ね」を封印する事にして「ぎょう」や「あたい」を登録したり、
「行末」を「ゆくすえ」と読まれたのは そっちかぁー と思いながら封印したりしてみました。
自分が作成した文章以外を読ませると、ボロボロになるかもしれないな....😓
AM中に起床。
Ollamaで音声解析ってできるんだっけ？と思ってちょろっと検索してみたところ、
方向は逆ですがテキスト読み上げを行う
VOICEVOXという音声合成ソフトの存在を知りました。
GUIを介してテキスト入力や読み上げの編集を行えるのですが、それとは別にREST-APIサーバーとしても
動作するようで、Cygwinだとbashコマンドラインからcurlを介して音声を再生するところまで実行
可能なようです。
| 原文 | ソースを弄ったEmacsをCygwin上で野良ビルドすると大分使いやすくなりました。 | |--------------+----------------------------------------------------------------------------------------------| | Edge読み上げ | そーすをもてあそったいまくをさいぐいんうえでのらびるどするとおおいたつかいやすくなりました | | VOICEVOX | そーすをいじったいーまっくすをしぐうぃんじょおでのらびるどするとだいぶつかいやすくなりました |
#!/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
* ** 以下の日本語の読み方を示してください。 - 旅行に彼と行ってみました - 準備を彼と行ってみました ご提示の文の読み方は以下の通りです。 - 旅行に彼と行ってみました → *りょこうに かれ と いってみました* - 準備を彼と行ってみました → *じゅんびを かれ と いってみました* --- 💡 *補足（より自然な表現について）* 日本語の語順やコロケーション（語の結びつき）の観点から、以下の点をご参考までに申し上げます。 1. *旅行に彼と行ってみました* 文法的に間違いではありませんが、ネイティブは通常主語や関連する名詞を先に持ってくるため、 =彼と旅行に行ってみました=（かれと りょこうに いってみました）の方が自然です。 2. *準備を彼と行ってみました* 「準備を行う」は正しい表現ですが、「〜と行ってみる」という組み合わせは少し不自然に響く場合があります。文脈にもよりますが、以下のように言い換えるとより自然です： - =準備を彼としてみましたが=（試した結果、何か分かった・わかった） - =準備を彼としましたが=（ただの共同作業） - =準備を彼と揃えました／共同しました=（文脈次第） 必要に応じて文脈を教えていただければ、より適切な表現にご提案できます。
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)