昔の最近の出来事(2024.09)

2024/09/30

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

flymake。まだちょっと怪しい所があるのですが、リモートでmake実行した結果をエラー表示できるようになったり。 一時ファイルに保存したコードをチェックするので多少の突っかかりはありますが、まぁイケるかなという感じ。

そいえば、flymakeのテストはD言語で特に意味の無いコードを書いてわざとエラーさせたりしながら 実験していたのですが、gcc 14.2ベースの gdcだと やたらエラーメッセージが出るなぁ？ と思ったりも。セミコロンが抜けているだけでも色んな所がエラー指摘されるのはなんでだ？🤔

AM中に起床。

ちょろりお出かけ。リロードしたら新一万円札が数枚混ざっていたり。 連番だったので、もしかすると以降は新一万円札しか出てこないATMになっていたのかも。

flymake。弄っているうちに動きが変になったり。関数unwind-protect のbody-formの 位置を間違えてたのが原因だった模様。if もそうなのですが、デバッグメッセージを 出すようにするとき、油断するとprognやletでブロックを形成し忘れていて、 メッセージは出るけど動きが変ってなってしまいます。

(let ((condition t))
  (if condition
      (func1)
    ))

↓↓↓message出力を足しただけのつもりが.....

(let ((condition t))
  (if condition
      (message "msg")
      (func1)
    ))

AM中に起床。

flymake。flymakeの infoに記された make向けのサンプルコードを参考に 動きを調べているのですが、なんとなく仕組みが判ってきたようなそうでも無いような。 ruby向けのサンプルでは Makefile無しの代わりに バッファの内容を syntax check実行モードで 起動したrubyプロセスの標準入力に流し込んで、得られたエラーメッセージをパースして 元のソースコードのバッファにチェック結果を反映するという仕組みのようです。 flymake的には一時ファイルを生成するか否かは外出しの関数次第のようなので、 リモートで実行するか否かを考慮してファイルパスなどは加工する必要があるみたい。
どのような言語でも makeを介して コンパイラなりインタプリタなりLintなりを実行し、 得られた結果文字列をパースすれば こんなに面倒な事にならない気も。 makeを使う ひと手間をサボると面倒臭い事になるようには思ったりも。

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

実験。うーむ、わからん。

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

調べ事。

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

ちょろり調べ事。

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

Emacsのinfoでflymakeを調べると、Flymakeとして独立したinfoページにリンクがあるのを知りました。 中に ruby-flymake.el というサンプルコードが載っていて、 flymake-proc.el 内の 関数flymake-proc-legacy-flymake を ruby向けに実装するような感じのが記されているようです。 因みに ruby-flymake.el は lispディレクトリには存在しないもののようです。なんで？🤔 さておき、これをテンプレにして考えろって事なのか？と思ったりも。敷居が高い.....

AM中に起床。

掃除したり。

リモートディレクトリのflymake。 何やらエラーしているのですが、どこを見てエラーと言っているのかがよく判らず。 前からそうなのですが、flymakeは実行した結果がどこにも出ないので、 見れば原因が判るようなエラーメッセージも見る事ができず、何が悪いのかがさっぱり判りません。 その後も弄ってみたのですが調べ方の要領が得られず挫折気味🥺

AM中に起床。

リモートディレクトリのflymake。 一つは makeのオプション -C で実行するディレクトリを指定しているのですが、 これが tramp-file-name(/method:user@host:/pathto/) になっているというのがありました。 もしかしてこれを最後のパス指定に変えれば動くのか？と思って試してみたのですが、 make-processではやっぱりダメそう。

26.3時代のmake-processではリモート実行はできないようで、 リモートディレクトリでプロセスを実行したければstart-file-processを使用しなくては ならなかったようですが、27.1から :file-handler というキーワードを使えばリモート実行が できるようになっているもよう。で、少なくとも Emacs30の flymake-proc.el 内 関数flymake-proc-legacy-flymake で実行している make-process実行では :file-handler は 指定されていませんでした。先の make の -Cオプションの指定を適当にごまかして make-process に「:file-handler t」を指定してみたのですが、なにやらよく判らない挙動になったり😓。 うまくいきません。

「:file-handler t」を入れない時は「make ....」をローカルで実行していてエラーという感じだったのですが、 「:file-handler t」を追加すると、何故か「/bin/sh -i」というコマンドを実行しているようで、 エラーの原因が違っています。どういうこと？🤔 もう少し調べてみると、エラーはしているのですが、 リモートでshは実行されているようで、現状は実行してエラーする度に shのプロセスが終了せずに 増え続けているという状況でした。-iなのでインタラクティブシェルとして起動されているようですが、 終了せずに留まり続けられるのだっけ？🤔

AM中に起床。

EmacsのTRAMPを使ってリモートのVMやその中で動いている コンテナの中のファイルを編集する事ができます。 リモートディレクトリのdiredバッファや、リモートのファイルを開いているバッファで「M-x shell」を実行すると、 何気にリモートで実行されたshell(つまりsshログインやコンテナ execした状態)のターミナルになるのを知りました。 因みに、カスタム変数 explicit-shell-file-name の設定に bash.exeって書いてあったせいで起動できなかったのですが、 拡張子を削ってOKになりました。
で、flymakeもリモートでmake実行できないのだっけ？🤔と思ったり。 以前、リモートのpythonソースファイルをflake8でチェックできる というのを知った訳ですが、リモートファイルをパイプでローカルのflake8に食わせるという方法でした。 単一ファイルの場合はそれでも良いのですが、makeを使うようなプロジェクトだと、 ソースファイルだけがリモートにあって、ローカルのmakeやコンパイラを使ってチェックするという事は あり得ません。単純にリモートで make実行したコンパイル結果を flymakeのエラー表示などに使うように 考えれば良いと思われます。で、M-x shellでリモートシェルが起動できるという事は、makeコマンド も同じように実行すれば良い(事前にflymake用の 一時編集中のファイルを書き出す必要はあるかも知れませんが)ハズで、 M-x shellでここまでできているのなら、flymakeで実行するコマンドもリモート実行できる状況にあるんじゃないのか？ と思った次第です。ただ、どうにも flymakeと TRAMPを組み合わせた例がWebで見当たらず。 できないけどそのような使い方をする場面が無いので誰も困っていないのか、 実は特別な事をしなくても(TANEの設定がマズいだけで)出来るので誰も困っていないのかはよく判りません😓。 少し調べてみるか....

そういえば、Emacs30では 何故か.emacsに「(require 'flymake-proc)」を追加する必要があるようなのですが (以前のメモ)、flymakeの下請けにflymake-procがあるのだと 勝手に思っていたのですが、どうやら flymake-procの下請けが flymakeのようだったり。 Emacs29.4では flymakeの中(何故か最後の行)で「(require 'flymake-proc)」が記されているのですが、 Emacs30ではその行が無くなっているようです。flymake-procでは Emacs29.4もEmacs30も 「(require 'flymake)」が含まれているので、設定的には「(require 'flymake-proc)」の方が 必要という関係になっているようです。ただ「そうなんだっけ？🤔」感は拭えません。
で、flymakeでのチェックプロセスの実行は flymake-proc.el内の 関数flymake-proc-legacy-flymake で行なわれているようですが、make-processでプロセス実行されるみたい。 かつては flymake.el内で、start-file-process を使ってリモートでコマンド実行するようになっていた ようですが、2017年8月17日のコミット fe9dc7a08 で現在のflymake.elとflymake-proc.elに 分離されたようです。そのすぐ後の 2017年8月23日のコミット 6954270e8 で start-file-process を使っていたのが make-process に変えられて、今に至るという感じみたいです。 ぶっちゃけ、ここで(ローカルでしか動かないように)ぶっ壊してるんじゃ？と思わなくもありません。

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

調べ事をして終了。

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

Emacsのmasterブランチ(31系)に src/w32.cと src/w32fns.cというコードで ctype.hの代わりに c-ctype.hというヘッダを使うようになり、例えば 関数isalpha() を c_isalpha() に置き換えるという変更が加えられているようです。 c-ctype.hって何？ってのがよく判らないってのもあるのですが、 src/w32fns.cは Cygwinでも使用しているので コンパイルが通らなくなるような気がしたりも。

もう少しWeb検索してみると c-ctype.h は「Gnulib」 由来のヘッダらしい。てかこれ、現状で ctype.hの関数で動いているものを わざわざ c-ctype.hの関数に置き換えるメリットって何だ？🤔 とは思ったりも。 もう少し git logを辿ってみたところ、色んな所で c-ctype.h に変更しているみたい。 どうやらマルチバイト文字に対応するという理由があるみたいです。

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

調べ事をして終了。

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

Unicode16.0。今回は追加される絵文字の数は少ない気が。 なぜこれらを絵文字に定義しようと思ったのかはよく判りませんが。 そういや、まぁまぁな数のヒエログリフが追加されるらしいのですが、 こちらは絵文字ではないので 例えば「Noto Sans Egyptian Hieroglyphs」 とかで対応されたフォントをインストールすれば表示可能になると思われ。 因みに、先週末に Emacsのmasterブランチ(31系)に Unicode16.0対応が入ったようです。

AM中に起床。

掃除したり。

そういえば、Emacsの find-dired/find-name-diredでリモートマシンのファイル名に空白が含まれていたり マルチバイト文字を使っていた場合に クオートされた表示になるのですが、それだとファイル名を選択しても そんなファイルは無いと怒られてしまいます。 ローカルファイルだとクオートはされていないので、関数start-file-process-shell-command で返ってくる結果文字列がクオートされているところから、何かしらリモートプロセス実行した際に どこかでクオートされているのかしら？と思ったり。

ls の manを見てみたらクオートするか否かをコントロールするオプションがあるのを知りました。 utf-8でリモートのlsが文字列を返してきて、バッファのコーディングシステムがutf-8という前提であれば、 カスタム変数find-ls-option を

(setq find-ls-option
      '("-exec ls -ldN --show-control-chars --time-style=long-iso --group-directories-first {} +" .
        "-ldN --show-control-chars --time-style=long-iso --group-directories-first"))

AM中に起床。

以前、Emacsのfind-diredのlsオプションに --group-directories-first を指定しても効いていないなぁ？と思ってそのままになっていました。 おもむろに調べてみた所、findの実行結果をEmacs側でソートし直しているのが判りました。 カスタム変数 find-dired-refine-function を nilに設定すれば find+lsの実行結果が 加工されなくなるので --group-directories-first が効いたように表示されます。 しかし、findで見つかる ファイル/ディレクトリ の数が多すぎる(lsに渡す引数が長すぎる)と、 find側の方で自動的に何回かに分けて lsが実行されているようです。 このため、分割実行毎にディレクトリがまとまるけど、全てのディレクトリが最初の方にまとまらない 場合があるという事になるようです。 例えば、Emacsのソースの最上位ディレクトリ下で、「M-x find-name-dired」のワイルドカードを「*」とか にして全ディレクトリ/全ファイルを表示しようとすると ダメな場合があるという感じです。 なんかうまくいかない🥺。 でも、実際にfindしたいのはファイルの方が多いと思いますので、実用上は問題にはならないかも知れません。 という訳で、しばらくfind-dired-refine-functionを nilに設定して使ってみよう。

以前、「結合文字の濁点」と言うものがあるのを知ったのですが、 Emacsでたまたま設定していたフォントで表示するとなんか違う感じに思ったり。 どうやらフォントによって上手く表示される場合とされない場合があるのが判りました。



「源ノ角ゴシック」はうまく表示されていますが、「Noto Sans Mono CJK JP Regular」は半濁点が微妙です。 「源ノ角ゴシック」がルーツとなっている「HackGen」は半濁点がイマイチです。 意外に思ったのは「BIZ UDゴシック」がダメらしい所。 BIZ UDゴシックがダメなのに関係あるのかは判りませんが、 「UDEV Gothic JPDOC」は何故かあ行の濁点/半濁点が微妙な感じです。 BIZ UDゴシック以外の Microsoftのフォントは何気にイケてます。 普段使いは「MeiryoKe_Console」なのですが、こちらもメイリオが元になっている為かイケてます。 改めて比べてみると 普通にイケるのは実はスゴイ事なのかもと思ったりも。

本当に「BIZ UDゴシック」でダメなんだっけ？と思い、最近のEdgeでは等幅フォントに 「BIZ UDゴシック」が設定されている(以前のメモ)ので 確認してみたところ、

あ゙い゙ゔえ゙お゙あ゚い゚う゚え゚お゚
がぎぐげごか゚き゚く゚け゚こ゚

あ゙い゙ゔえ゙お゙あ゚い゚う゚え゚お゚
あいうえおあいうえお  ←濁点/半濁点無し

がぎぐげごか゚き゚く゚け゚こ゚
かきくけこかきくけこ  ←濁点/半濁点無し

AM中に起床。

エアコンの水漏れ対策その後。大丈夫そうなので 避けていたTV台などを元の位置を戻したり。

Windows11で Emacs 30.0.91のテスト。の前に Windows10のPCで AVIF対応とかEmacs以外で色々弄っていたのを反映したり。 反映後に 30.0.91をビルドして起動。大丈夫そう。 Unicode15.1の絵文字は Windows11じゃないと 確認できないので地味に面倒臭いです。
そういえば全く気にしていなかったのですが、emacsの実行ファイルって stripしないと130MBくらい あるなぁと思ったり。stripすると 8MBくらいになるので大分色々シンボルが付いているという感じかも。

そういえば、以前 D言語でも 多重ループを脱出する のに ラベルドステートメントが使えるのを知ったのですが、自作の d-ts-modeで何気に試すと インデントができないなぁというのに気づいたり。対応してなかったっけ？ 毎度 tree-sitterのインデント対応はどう書けばよいのか判らないので、こうか？と思い 適当に試したところ、それっぽい感じにはなった気が。ただし d-modeとちょっと違う感じなのが イマイチな気も。
ところで、誰かもっと良いd-ts-modeを作っていたりしないだろうか？と思って検索してみたのですが 見当たらず。

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

libjxlの v0.11.0がリリースされているらしい。

Emacs 30.0.91。IMEその他のパッチを少し見直したり。
いつもの感じでイケば 1ヵ月毎に 30.0.93くらいまでプリテストがリリースされて、 年末か遅くても来年の初めには30.1がリリースされる感じになるのかなと思われます。

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

昨日 Emacs 30.0.90 の話を記したのですが、30.0.90では問題があったらしく、 Emacs 30.0.91 でリリースされた模様(Emacs 30.0.91 pretest is available)。

早速、手元の 30.0.60(のあるタイミング版)から作ったパッチを 30.0.91 に当ててみたり。リジェクト無しで当たり、 ちょろっと使った感じでは特に問題は無さげ。 ただ、以前対応した admin/unidata/emoji-zwj.awk スクリプトは パッチで新しくなってもそれを使ってデータを再生成しないので、予め admin/unidata の下で「make clean && make」とかしてから emacs本体の方を makeする必要があります。 という訳でしばらくテストしてみよう。

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

エアコンの水漏れ対策その後。今のところ水漏れは無し。

先日、Emacs30系ブランチで バージョンが 30.0.90 になってるらしいと記したのですが、 偶然にも emacs-30.0.90ってタグが打たれたコミットが行なわれたみたい。 でも、そのすぐ後に(不足していた？)configure.acのバージョン番号追従のコミットが入ったりしていて、 アーカイブにするにはまだ準備が整っていない状態なのか？という気がしたりも。

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

エアコンの水漏れ対応で電気屋さんに診てもらったり。 ドレンパンにゴミでも詰まっているのかと思ったのですが そうでもないっぽい。 ひとまず室内機のクリーニングを実施する事なったのですが、作業を見てたけどなかなかに面倒臭い。 でも本体奥に見えるファン(ラインフローファンとかクロスフローファンと呼ぶらしい)に引っかかっていた ホコリが綺麗に除去されました。ドレンパンとかも一通り掃除して完了。 数日様子を見る事になりましたが果たして....。 因みに、掃除前に冷房運転していたのですが 今日は水が溢れる事は無く。 おとといや昨日に比べて今日は冷却が追い付かないような気温ではなかった為か？

そういや、以前 Cygwinビルドで harfbuzzの DLLがロードできていない件 が修正されたとき、Cygwinじゃ無い場合のコードが壊れているんじゃないか？と記したのですが、 修正された模様。

ところで Emacs30 は 30.0.90 ってバージョンにいつの間にか上がっているようですが、 ソースアーカイブってリリースされないんだっけ？ いつも x.y.90代のアーカイブがいつの間にか pretestの置き場に置かれていて アナウンスあったっけ？ってなるのですが、30.0.90は置き場にアーカイブが無く、 アナウンスもされていないように思います。ルールがよく判らん。

本日休業。役所手続きとか色々。

「Turing Complete」 というCPUを作るゲームがあるというのを知ったり。ほぅ....

AM中に起床。

掃除したり洗濯したり。

エアコンから大量の水が落ちてきて水浸し。ひとまず運転を止めたけど暑くて死亡。

2024/09/07

AM中に起床。

日が暮れた頃に散髪にお出かけ。

「Emacsの雑記」を更新しました。 文章の微改版ついでに、以前対応したImageMagickのパッチ更新も 行なってみました。御参考まで。

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

Web巡回して終了。

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

あまりの眠さに急速停止。

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

screen 5.0.0 のCygwinビルド。 コンパイルエラーやリンクエラーになる関数呼び出しを行なわないようにして取り合えず 起動だけできるようにしてみました。 hardstatusの色指定の互換性が無くなっている点については、 以前、gitのmasterを試した時に調べた通りに 移行すれば大丈夫そう。前試した時は気づいていなかったのですが、 色味が若干違っていたのを少し調整して以下のような感じになってみました。



フルカラー表示になっているようです。ちゃんと対応されたものはCygwinパッケージで リリースされるのを期待しよう😅。

そういえば、最初に screen 4.x向けの .screenrcを読み込んだのですが、日付と時刻が表示されてるなぁ？ と思ったり。以前 git masterを試した時は hardstatusに 日付(%Y/%m/%dなど)や時刻(%c)を表示する組み込みの方法が無くなって、 外部コマンドを実行しなくてはならない事になっていましたが、5.0.0では取り下げられているみたい。 なので、色指定をフルカラー指定に変更する以外はそのままで大丈夫そうでした。 外部コマンドでの対応も可能なので(今回のスナップショットはそれで対応したもの)、 日付や時刻以外のものを表示したい場合は外部コマンドで文字列を得て表示する事は可能と思います。

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

GNU screenの 5.0.0がリリースされているらしいのを知ったり。 最寄りのftpサイトからソースアーカイブをダウンロードしてCygwinでビルドを試みたのですが、 PAM が見つからなくてエラー。 なんか以前見た記憶が。 PAMを外してみたのですが、コンパイルエラーでビルドできず。むーん。

そういえば、いつからか tarコマンドはアーカイブが圧縮されていれば自動的に判定＆展開されるのを知りました。 習慣的に「xz -dc foo.tar.xz | tar xf - 」みたいに実行しているのですが、 かつて 「tar xf foo.tar.xz」を「tar cf foo.tar.xz」と間違えるとファイルが壊れる事が あったからという理由でした。今のtarコマンドだと「空のアーカイブ作成はご容赦願います」って エラーになって元のアーカイブファイルが壊れる事は無いみたいです。 ただし、バックアップから戻す目的で「tar xf foo.tar.xz file1 file2」みたいに 所望のファイルを上書き展開するつもりが 間違えて「tar cf foo.tar.xz file1 file2」って やってしまうとやっぱりダメなのですが😓。 オプションがイマイチどう解釈されるのか今だに慣れないのと、 ssh接続した リモートマシンとの間で データ転送するときの応用を忘れないようにする為に、 これまで通り 圧縮/展開プログラムと tar はパイプで繋ぐスタイルで行きたいと思います。

先日、Edgeで使用するフォントが変わっている話を記したのですが、 Chromeも 標準フォントに「Noto Sans CJK JP」を、固定幅フォントに「BIZ UDGothic」が使用される ようになっているようです。「Noto Sans CJK JP」は たまたま我が家のPCには インストールされていたのですが、入っていなければどうなるのだろうか？ 因みに 現在はダウンロードできないっぽい？

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

調べ事をして終了。

昼頃起床。寝すぎ。

掃除したり。

Emacs30では アンダーラインのスタイルが追加されるらしい。



どうやって指定するのか判らなかったのですが、ELISPのinfoの Face Attributes によると 「:underline」にリストで追加のアトリビュートを指定する感じらしい。 「:style wave」は Emacs29とかでも使えていたようですが、Emacs30では double-line、dots、dashes が追加されるという事みたい。wave以外は text-scale-adjustにも適度に追従するみたいですが、 waveだけは追従しないっぽい。なので解像度によってはよく見ないと波線と判らないかも知れません。

たまたま underlineの近くに slantの説明があったのを何気にGoogle翻訳すると italicも obliqueも 「斜体」って翻訳されるなぁ？と思ったりも。 以前知った通り、厳密にはイタリック体と オブリーク体(斜体)とは違うものですが、Google翻訳では厳密に使い分けられてはいないようです。 この為、例えば 英語の「Italic type」の Wikipediaページを日本語に翻訳すると タイトルが「斜体」になるようです。 でも、翻訳された内容は「真のイタリック体」と「斜体」という風にちゃんと使い分けて 翻訳されているようです。ただし、文を選択してそこだけ翻訳するとやっぱり「Italic」が「斜体」と 訳される場合があって、翻訳結果に揺れが生じるみたい。