テレワーク。早くもなく遅くもなく終了。
先日の diredで複数選択したファイルを開く件。Web検索したら
こちらのような
やり方を知ったり。なるほど。
テレワーク。遅めに終了。
そういえば、夏前くらいにInkscapeの1.4が来るのかしら？と思っていたのですが、
まだ動きは無いみたい。
そういえば、Emacsのdiredで複数のファイルを選択して、それらを開くことってできないのだっけ？
と思ったりも。頻繁に使うものではないかも知れませんが。
テレワーク。気持ち早めに終了。
パリって緯度的に北海道よりも北になるのか。暑さ対策的なものは不要なのね。
先日の 電卓。というか英語。「数式」をGoogle翻訳したらformulaって出てきたのですが、
そういやexpressionじゃないのだっけ？と今頃思ったり。math expressionも「数式」って翻訳されたので
日本語的には使い分けがよく判らんと思ったりも。
で、調べてみた感じ formulaは「公式」的な意味合いが強いらしい。
という訳で先日のELISPコードは シレっと expressionに変えておきました😅。
昼前起床。
掃除したり洗濯したり。
そういえば、自分以外の人がテキスト編集をどうやってるのかってあまり見たこと無いなぁ？
と思ったりも。たまに 本物お仕事のオンライン打合せで、ちょこっと直すだけ(とういう想定)
みたいなのを見ていると、割とちょこっと感の無い方法で編集しているなぁ... と思う事はあります。
| aaaaa bbbbbbbb
| cc ddddd
| eeeeeeeeeee ffffffff
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
|aaaaa bbbbbbbb
|cc ddddd
|eeeeeeeeeee ffffffff
(defun my-calc (expr) "my simple calc" (interactive (list (read-from-minibuffer "expression: "))) (insert (calc-eval expr)) )
昼過ぎ起床。寝すぎ。
Linuxやネットワークを含んだテストにVMwareを使っているのですが、ネットワーク経由の
ファイルアクセスを行なった際にやたらCPUを食うのとアクセスが遅いのが気になっていました。
で、VirtualBoxだとどうなのだろう？と思い試してみていました。
Windows10ホストのCygwin Emacsから VirtualBoxの Fedora40上の画像ファイルで
image-diredを試した感じ、VMwareよりもCPUの負荷がかからないように見えます。
VMwareではネットワーク経由でファイル転送を行なうと
「VMware Workstation VMX」というプロセスが高負荷で動きます。
加えて Windowsの「Antimalware Service Executable」てプロセスも同時に動くようで、
これらがCPU高負荷だったりなんだかファイル転送速度が遅い原因みたい。
VirtualBoxにFedora40を新規インストールしたついでに Emacsとかもパッケージインストールしてみたり。
環境構築の過程の中でパッケージに
「emacs-anthy-unicode.noarch : Emacs files for anthy-unicode」
なるものが存在しているのを知りました。Emacs-29にも対応しているようです。
VMwareのFedora40では随分前に入れたanthyのパッケージがずっと引き継がれているのですが、
Emacs27になった時に動かなくなってしまい、
手動でパッチを当てていました。しかし、Fedoraをアップグレードする度にパッチが剥がれて
先祖返りしてしまい、毎回手で直すって事を繰り返していました
(過去メモ1,
2,
3)。
という訳でVMwareのFedoraも anthy-unicodeに変更してみました。
wrapped_convertをテストしていたのですが、色々バグらかしていたのを直したり😓。
BPGやJXRのリモート画像サムネイル生成に失敗していました。
テレワーク。遅めに終了。
D言語版の wrapped_convertをテストしていてSegfaultするケースがあったり。
ssh接続で失敗したとき、tmpファイルには何も書かれないのですが
std.file.deleteme()を使った場合、何か書かれるまでファイルの実体は生成されないようです。
このとき「scope(exit) tmp.remove();」みたいになっていると、
何か書かれてファイルが存在していれば tmp.remove() は成功するのですが、何も書かれていなくて
ファイルが存在しないと tmp.remove()がSegfaultするという感じになっていました。
D言語のサンプルコード通りにしていたのですが、うまく動かない場合があるという罠。
「scope(exit){if(exists(tmp)) tmp.remove();}」みたいに対応してみたのですが、
普通はどうするものなのかはよく判っていません😓
テレワーク。早くもなく遅くもなく終了。
先日の続き。D言語版の wrapped_convertを対応している途中で
何故かファイルのフレーム番号指定が解釈されなくて悩んだり。
原因は単なる勘違い。D言語版では パイプを使わない代わりに一時ファイルを介してリモートファイルを
ローカルにコピーしてから magick convertに食わせているのですが、
その時の一時ファイル名にフレーム番号を付けてしまっていたのが原因でした。
foo.gifという元ファイル名の場合 コマンド引数は foo.gif[0] のように指定するのですが、
一時ファイル名がtmp.gif[0]のようになっていても、これはフレーム指定した事にはならない
(tmp.gif[0][0]とかにしなくてはダメ)という事でした。
修行が足りません。ひとまず D言語版も対応できたつもり。
テレワーク。遅めに終了。
Emacsの image-dired でリモートファイルに対応する為の拙作スクリプト wrapped_convert を改善。
拡張子が .jfifだった場合に変換できなかったのと、アニメーションgif/webp でファイル名に
フレーム番号指定した場合(例えば foo.gif[0]とか)に変換できなかったのを対応してみたり。
テレワーク。遅めに終了。
調べ事をして終了。
テレワーク。遅めに終了。
Web巡回して終了。
昼過ぎ起床。寝すぎ。
掃除したり洗濯したり。
調べ事をしたりぐうたら過ごして終了。
そういえば Emacs30のブランチが生成されてから1ヵ月が経ちますが、そろそろ 30.0.90が来るのかしら？
タイミングがイマイチよくわからない。
昼過ぎ起床。寝すぎ。
先日から発生しているらしい大規模システム障害。
そういや我が家の Windows10 PCも数日前(7月19日より前)にスリープから復帰してちょっと使っていると
ブルースクリーン落ちして珍しいなと思った事があったな。
今の所、再起動後にブルースクリーンの再現はしていませんが、世の中では何度も発生するケースがあるらしい。
クラウドストライク社のセキュリティソフトに原因があったようですが、我が家では使用していないので
違う原因でブルースクリーン落ちしていたのではないかと思っています。
それにしても、直接関与しない 高々 一アプリに不具合があっただけで全体に波及するとは、
今の社会システムって脆弱だなぁとは思います。
そういえば先日、find-diredの話の中でも少し触れましたが、
ターミナルのコマンドラインでファイル名が判ったとして、起動済のEmacsで開こうとすると
フルパスが必要になる場合があります。
pwdコマンドを使用したり、bashの環境変数PS1でコマンドプロンプトに良い感じに表示されていたり
するものを コピペして ファイルを開くのに使用する(直接開ける訳では無い)場面は良くあります。
で、bashのコマンド文字展開に「~+」というのがあるのを知りました。pwdコマンド相当の
カレントディレクトリパス文字列に展開されます。
例えば「ls -l ~+/*.c」みたいするとカレントディレクトリの *.cにマッチするファイルが
フルパスで表示されます。
ファイルがフルパスで表示されるので カレントディレクトリに関係無く、
起動済みEmacsや コマンドのファイル名指定に使えます。
因みに「ls -l ~+/*」とかだと恐らく想定した感じにはなっていないのではと思います。
「ls -ld ~+/*」などのlsコマンドのオプションを上手く使う必要があるので微妙に面倒な所はあるかも知れません。
テレワーク。遅めに終了。
SAI2の新しいのが来ていたり。おつかれさまです。バグ修正がメインのようです。
キューの先祖返りの件。Emacs29.4の image-dired-external.el の関数image-dired-create-thumb
に 先日の対応を適用してみたのですが、
何度も サムネイルファイルを生成する事はなくなったものの、Emacs30のように
すぐに *image-dired* バッファの表示更新が始まる事は無いみたい。
29系でも直れば良かったのですがいたしかたなし。
テレワーク。気持ち早めに終了。
Web巡回して終了。
テレワーク。遅めに終了。
調べ事をして終了。
テレワーク。早くもなく遅くもなく終了。
キューの先祖返りの再現。
特別な事はしていないように見えるけどなぁ？と思いながらも違いを調べてみたり。
調べている中で、ファイルの属性を調べる 関数file-attribute-modification-time を使っている
のですが、defsubst てので宣言されているなぁ？と思ったり。
defsubstてなんぞ？と思って調べたところ、インライン関数を定義するマクロらしい。
なんか怪しい気がすると思い、関数(マクロ)の戻り値を一旦変数に置いたものをキューの登録データに使う
ようにしてみたところ、キューの先祖返りが発生しなくなるようでした。んー？ ほんとか？🤔
先日の最小コードに組み込んでみたのですが再現はせず。むーん🤔。
AM中に起床。
ちょろり買い物にお出かけ。
モロコシ死んでしまったのか....。確かに出てないな？とは思ったけれども。
先日のキューの先祖返りの件を最小コードで再現できないか？と思い試してみるも
先祖返りせずに意図通りに動く模様。再現できず。むぅ🤔。
AM中に起床。
掃除したり。
Emacs30.0.60のテストを始めた頃に
Emacs29でリモート画像ファイルのサムネイル表示が始まるのが遅い件について、
Emacs30では パッチが影響している事が判りました。
そういやそのパッチ外しをEmacs29では試していなかったな？と思い試してみたのですが、
Emacs29ではパッチを外しても状況が改善しませんでした。
動きとしてはEmacs30で調べてた時と同じで、サムネイル画像ファイルを作っては消すを繰り返していて、
一通り終わるとサムネイルが表示され始めると共にファイルも保存され始めるというものでした。
結局、Emacs30ではパッチ外しを行なった事でなぜイケるようになったのかの因果関係が結びついていない
ままなのですが、Emacs29ではもう少しちゃんと原因を追及しないとダメかも🥺。
少し見てみるも、やっぱりファイルが消える要素が見当たらないのだけどなぁ.....？🤔
よくよく観察していると、ファイルが消えているのではなくて、同じ名前で上書きされているっぽいのが判ったり。
変数image-dired-debug というimage-diredをデバッグする為の変数があった為、
それを使って動きを見てみたり。
どうやら、画像ファイルをマークする時に何やらサムネイルを生成しようとしているのですが、
マークされたうち最初の方の6個分のファイルの サムネイル生成を繰り返しているようでした。
この「6」はサムネイル生成を非同期実行する並列数(image-dired-queue-active-limit)分で、
我が家では 6に設定してあるという事です。繰り返し回数はマークしたファイル数か？と思ったのですが、
マークしたファイル数よりも少ない感じなのが謎。
さておき、それが終了するとマークを外していて、その後「*image-dired*」バッファへの
描画が始まるという感じのようです。
画像ファイルをマーク→マークを外すまでの間に、無意味なサムネイル生成を繰り返している
感じにはなっているという事みたい。
で、image-dired-queue という変数が まだ未生成のサムネイルの一覧がリストで格納されている
キューになっていて、空でなければ一つを取り出してサムネイルを生成するという感じなのですが、
何度も同じサムネイルを生成するには、キューが取り出されていない可能性が考えられます。
しかし、6個分の異なるサムネイルを生成しようとしているという事は、キューの取り出しは
できていると考えられるかと。てことは、同じ画像のサムネイル生成を何度もキューに登録
していると仮定するのが辻褄としては合うように思ったり。
と、当たりを付けて探りを入れてみるもよく判らず🥺
よく判らないけど リストの先頭を取り出す popが動いていないように見えるのだけど...？
もう少し キューの動きを観察したところ、キューのpop(先頭からの取り出し)はできてっぽいですが、
キューへの追加(nconcてのを使っている)を行なうと、何故かキューが popする前の内容に
戻っていて、それに対して追加しているように見えます。結果、pop側はまた最初からやり直している感じ。
同じ画像のサムネイル生成を何度もキューに登録しているというよりは、キューの内容が
先祖返りしてしまう為、見かけ上 何度もキューに登録している様にも見えるという感じみたい。
そもそもキューへの追加側とキューの取り出し側が別スレッドみたいな感じになっているのですが、
キューのインスタンスがスレッド共有になっていないかのような振舞いにも見えます。
29.xでは何かしらバグっているのかも。なので、30.0.60では直っててうまくいくようになった？🤔
30.0.60では 同期で行なうようにしていたパッチを外して非同期(run-at-timeを使う)に戻すと
動くようになりましたが、何かしらバグっていたとすれば因果関係が判らないのに直ったように
見えるってのも納得はできるっちゃできます。
いずれにしてもELISPが意図しない動きになっている以上はどうしようも無い感じ。
30系で直るって事にして 29系で直すのはあきらめる方向で😓。
30系で29系と同じデバッグコードを仕込んで動きを観察してみたところ、
キューへの追加が全て終わるまでは取り出しを行なわない動きになっているようです。
また、29系でもローカルディスクの場合は キューへの追加が全て終わるまでは取り出しを行なわない
動きになっていました。ただ、「取り出さない動きになっている」というよりは
「追加の間は取り出しが行なえない」のではないか？とも思ったり。
いずれにしても、なんかELISPの動きが怪しい気がします。
もしかしてこういう事が起こっているのか？と思ったり。
以下は若干パッチが当たっていますが 29.4 の lisp/image/image-dired-external.elの
キューの追加と取り出しのメインとなる二つの関数です。
1 (defun image-dired-thumb-queue-run ()
2 "Run a queued job if one exists and not too many jobs are running.
3 Queued items live in `image-dired-queue'.
4 Number of simultaneous jobs is limited by `image-dired-queue-active-limit'."
5 (while (and image-dired-queue
6 (< image-dired-queue-active-jobs
7 image-dired-queue-active-limit))
8 (cl-incf image-dired-queue-active-jobs)
9 (apply #'image-dired-create-thumb-1 (pop image-dired-queue))))
10
11 (defun image-dired-create-thumb (original-file thumbnail-file)
12 "Add a job for generating ORIGINAL-FILE thumbnail to `image-dired-queue'.
13 The new file will be named THUMBNAIL-FILE."
14 (setq image-dired-queue
15 (nconc image-dired-queue
16 (list (list original-file thumbnail-file
17 (format-time-string
18 "%s" (file-attribute-modification-time
19 (file-attributes original-file)))))))
20 (run-at-time 0 nil #'image-dired-thumb-queue-run)
21 )
AM中に起床。
例えば 全く土地勘のないディレクトリ構造の中で、ファイル名だけは なんとなくこんな感じ
っていうのが分っている時、findコマンドを使う事がよくあります。
「find . -iname '*image*.c'」のようなので ファイル名が分ったとして、
それを 既に起動しているEmacsで開こうとすると、ファイルパスをフルパスになるように
ごにょごにょ加工して...みたいに微妙なひと手間がかかるのですが、そういうもんだと思ってました😓。
で、Emacsに find-dired や find-name-dired というコマンドがあるのを知りました。
雑に要約すると findコマンドの実行結果を diredで表示/操作できる感じのものみたい。
find-name-diredは findコマンドの -inameオプションの引数を指定するファイル名検索に特化したもので、
find-diredは findコマンドの生オプション(例えば「-name 'Image*' -type f」とか)を細かく
指定したい場合に使うみたいです。
デフォルト設定で実行すると find コマンドの -lsオプションが指定されていて表示がイマイチなのですが、
変数 find-ls-optionで findコマンドの -execオプションを使った出力で調整する事もできるようです。
diredの普段使い設定が
「(setq dired-listing-switches "-la --time-style=long-iso --group-directories-first")」
みたいな感じなので、それと合わせる感じで
「(setq find-ls-option '("-exec ls -ld --time-style=long-iso --group-directories-first {} +" . "-ld --time-style=long-iso --group-directories-first"))」
てな感じにしてみました。変数find-ls-option のhelpを読む感じ、
(FIND-OPTION . LS-SWITCHES)のような設定の対になっているようですが、LS-SWITCHESは
findコマンド側で出力される lsの表示に合ったものを指定すれば良いみたい。
でも、--group-directories-first は効いてなさげ🤔。
個人的に TRAMP接続した場合でも使えるか？ が重要だったりするのですが イケるようです。
スゴイ😲。
ただし、「*Find*」というバッファを共用するようです。なので
ローカルとリモートで探した結果を見比べるみたいなのは少し手間をかける必要がありそうですが、
ターミナルでローカルとリモートで findコマンドを実行して もにゃもにゃするよりは少しマシ
かも知れません。
dired表示の1行目にディレクトリパスが表示されていますが、
たまたまマウスカーソルがパスの途中に乗っていて、なにやらクリッカブルになっているのに気づいたり。
クリックしてみると(Windowsのファイルエクスプローラと似た感じで)クリックしたディレクトリ階層が
diredで表示されるというのを偶然知りました😅。テキストカーソルを移動して RETでも同様に開く事が
できるというのも知ったのですが、マウスカーソルをかざした時と違ってハイライトもされなければ
ToolTipが開く訳でも無いので、まさか開けるとは思わなかったという感じです。
find-diredの話も含め、毎度の事ですが まだまだ知らない事が沢山あるなぁと思います。
テレワーク。遅めに終了。
Web巡回して終了。
テレワーク。遅めに終了。
Emacs 30.0.60でのstippleパターン表示。
0x80以上の文字がマルチバイト文字として文字列に含まれていた為、bitmap生成関数でうまく
値が取り出せない状況になっていたみたい。
「:stipple (list 8 8 (string ?\x1 ?\x2 ?\x4 ?\x8 ?\x10 ?\x20 ?\x40 ?\x80))」みたいに
データを指定した場合、最後の 0x80がユニバイト文字になりません。
「:stipple (list 8 8 (string-to-unibyte (apply 'concat (mapcar 'byte-to-string '(#x01 #x02 #x04 #x08 #x10 #x20 #x40 #x80))))」
て感じにすれば 0x80を含むユニバイト文字列としてbitmap生成関数にうまく伝わるようです。
なんか面倒臭いですがこういうものらしいという事で。
テレワーク。気持ち遅めに終了。
Emacs 30.0.60でのstippleパターン表示。
なにやら8x8サイズにすると一部データが化けているように思ったので、デバッグコードを仕込んで観察してみたり。
確かに化けてっぽいデータが渡ってきているようなのですがなぜそうなっているかはまだ分らず。
そういやデータ指定する場合は文字列データで指定する事になっていますが、
0x80以上ってASCIIコード的にどういう扱いなんだっけ？🤔
テレワーク。気持ち遅めに終了。
Web巡回して終了。
テレワーク。早くもなく遅くもなく終了。
Emacs 30.0.60 で text-scale-adjustでスケールを変更すると stippleパターン表示が変になる場合がある件。
先日 bitmap_idが重複して割当たっているという所から探ってみた所、ここかな？というのを見つけたり。
src/image.c内の 関数image_create_bitmap_from_file() と 関数image_create_bitmap_from_data() が
bitmapを読み込んでパターンテーブルに登録する関数のようです。
bitmap_idの払い出しは 関数image_allocate_bitmap_record()で行なっていて、基本的には新しいテーブルを
登録したら新しいIDを払い出しているのですが、リファレンスが無くなったテーブルエントリはそのID
を再度払い出すというロジックのようです。IDが増えないのは、このリファレンスが無くなった
テーブルエントリを再払い出しする時のようです。ただ、関数 image_allocate_bitmap_record() では
IDの払い出しを行なうだけで、リファレンスの有無を示すリファレンスカウンタはこの関数の外で
正しく制御する必要があるみたい。
で、長くなりましたが、データからbitmapを生成する 関数image_create_bitmap_from_data() では
bitmapの読み込みに成功したら リファレンスカウントを1 にしているのですが、
ファイルからbitmapを生成する 関数image_create_bitmap_from_file() では
プラットフォーム毎に ifdefブロックが別れていて HAVE_NTGUIの場合を確認すると
リファレンスカウンタを設定するコードが抜けているようです。HAVE_PGTKなど他のブロックを参照すると
いずれも リファレンスカウンタを1 にしているようです。
データからbitmapを生成する 関数image_create_bitmap_from_data() ではリファレンスカウンタの
設定は共通コードで実行するようになっていますが、
ファイルから bitmapを生成する 関数image_create_bitmap_from_file() は共通コードは無いように
書かれているので各ブロックで漏れなく記す必要があるかと思われます。
$ diff -u src/image.c.orig src/image.c --- src/image.c.orig 2024-07-06 11:40:39.726123700 +0900 +++ src/image.c 2024-07-08 23:23:25.459487200 +0900 @@ -780,6 +780,7 @@ id = image_allocate_bitmap_record (f); bitmap = w32_create_pixmap_from_bitmap_data (width, height, data); + dpyinfo->bitmaps[id - 1].refcount = 1; dpyinfo->bitmaps[id - 1].height = width; dpyinfo->bitmaps[id - 1].width = height; dpyinfo->bitmaps[id - 1].stipple = bitmap;
昼過ぎ起床。寝すぎ。
掃除したり洗濯したり。
Emacs 30.0.60 で text-scale-adjustでスケールを変更すると stippleパターン表示が変になる場合がある件。
デバッグコードを仕込んで様子を少し見てみたり。
src/w32term.c内の 関数 w32_fill_stipple_pattern() が実際に Win32APIの CreatePatternBrush()と
FillRect() を使ってパターン描画を行なっている箇所になるのですが、
パターンの一覧を保持した bitmapsという配列から face毎に保持されているパターンの選択値を使って
描画するパターンを選択しているようです。しかし、face毎に保持されているパターンの選択値が
既に壊れている場合があるようで、この関数では壊れた値の通りのパターンで描画しているだけと
いう感じみたい。どこでface毎のパターン選択値が化けているのかを調べる必要がありそう。
もう少しだけ調べてみた所、src/xfaces.c 内の 関数load_pixmap() でface毎のbitmapをロードしている
ようなのですが、 何故か違うパターンに対して同じ bitmap_idを返す場合があって、
これが選択を誤る(というか返ってきたIDに従っているだけですけど)直接の原因になっていそう。
なぜそうなるのかはまだ判らず。
AM中に起床。
Emacs 30.0.60 を今日時点の最新にしてみたり。
少し前に、
Cygwinのw32ビルドで harfbuzzの DLLがロードできていないバグが修正されてっぽいと
記したのですが、UNICODE=1でビルドするとワーニングになる箇所があったので微妙に直したり。
あと、Cygwinじゃない場合のコードが壊れてるんじゃないか？
変数uniscribe_availableを 1にするコードが WINDOWSNT(MinGWとか)の場合に機能しなくなってるように思ったりも。
ちょろっと動かしてみた感じではいきなりズッコケたりはしなさげ。
そういやVMware上で動いているFedoraで Emacsを起動して、クライアントの VcXsrvで受けて
表示するってのをこれまでもやっていたのですが、なぜか開かなくなっていたり。
同じようにImageMagickのdisplayコマンドを実行すると開くので、環境変数DISPLAYの設定とかは合っているハズですが？🤔。
もしやと思い、VMware上で開いたデスクトップをログアウトしたら開くようになったり。
でも、なにやらメッセージ表示のウインドウも同時にひらいて、
「You are trying to run Emacs configured with the "pure-GTK" interface under the X Window System. That configuration is unsupported and will lead to sporadic crashes during transfer of large selection data. It will also lead to vanous problems with keyboard input. Install emacs-gtk+x11 or emacs-lucid package.」 (Google翻訳: X Window System で「pure-GTK」インターフェースで構成された Emacs を実行しようとしています。この構成はサポートされていないため、大規模な選択データの転送中に散発的なクラッシュが発生します。また、キーボード入力にさまざまな問題が発生する可能性があります。 emacs-gtk+x11 またはemacs-lucid パッケージをインストールします。)
0 1 2 3
0:１１００
1:１１００
2:００１１
3:００１１
気持ち早めに帰着。
調べ事をして終了。
テレワーク。気持ち早めに終了。
Web巡回して終了。
テレワーク。気持ち早めに終了。
先日の「⛓️💥」のシーケンスが足されると「⛓(VS16無し)」と「⛓️(VS16有り)」の切り替えができなくなる件
の対応を Emacs-29.4にも行なってみたり。
以前から Emacs-29.1で Uicode15.1対応して使っていたのですが、
emoji-listとかでも「⛓」だけがSegoe UI Symbolで表示されているのは まるで気づいていませんでした😓。
てか、今回のも Windows11で Unicode15.1の絵文字表示が対応されたのに たまたま「⛓️💥」が表示できていない
のに気づいた所が発端になっている訳ですが、もし「⛓️💥」が表示できる方に倒れていて、
「⛓(VS16無し)」と「⛓️(VS16有り)」の表示が切り替わらないだけだったら、変な事に絶対気づいて
いなかったかも。
librsvgって現在はRustに移行しているってのを知ったり。CygwinネイディブなRustコンパイラは無いので
面倒臭い事になっているかも。
gcc-14.1では gcc-rustが実験的に入っているようですが(以前のメモ)、
Cygwinで使えるようになるのかは判りません。結局 gdcも gcc-12以降 ブートストラップできなくなるのですが
(以前のメモ)、
Cygwinで動くlibdruntimeやPhobosがビルドされそうな気配は無いですし。
テレワーク。早くもなく遅くもなく終了。
Emacsで「⛓(VS16無し)」と「⛓️(VS16有り)」で表示が切り替わらない件。
順番に Unicode15.1から15.0に近づけてみようと試してみたら、1つ目の変更で切り替わる状態になったり😅。
$ diff -u admin/unidata/emoji-zwj.awk.orig admin/unidata/emoji-zwj.awk
--- admin/unidata/emoji-zwj.awk.orig 2024-06-25 22:42:47.000000000 +0900
+++ admin/unidata/emoji-zwj.awk 2024-07-03 00:59:54.674572700 +0900
@@ -70,18 +70,19 @@
# try to display them with the emoji font anyway.
trigger_codepoints[1] = "261D"
- trigger_codepoints[2] = "26F9"
- trigger_codepoints[3] = "270C"
- trigger_codepoints[4] = "270D"
- trigger_codepoints[5] = "2764"
- trigger_codepoints[6] = "1F3CB"
- trigger_codepoints[7] = "1F3CC"
- trigger_codepoints[8] = "1F3F3"
- trigger_codepoints[9] = "1F3F4"
- trigger_codepoints[10] = "1F441"
- trigger_codepoints[11] = "1F574"
- trigger_codepoints[12] = "1F575"
- trigger_codepoints[13] = "1F590"
+ trigger_codepoints[2] = "26D3"
+ trigger_codepoints[3] = "26F9"
+ trigger_codepoints[4] = "270C"
+ trigger_codepoints[5] = "270D"
+ trigger_codepoints[6] = "2764"
+ trigger_codepoints[7] = "1F3CB"
+ trigger_codepoints[8] = "1F3CC"
+ trigger_codepoints[9] = "1F3F3"
+ trigger_codepoints[10] = "1F3F4"
+ trigger_codepoints[11] = "1F441"
+ trigger_codepoints[12] = "1F574"
+ trigger_codepoints[13] = "1F575"
+ trigger_codepoints[14] = "1F590"
print "(setq auto-composition-emoji-eligible-codepoints"
print "'("
テレワーク。早くもなく遅くもなく終了。
調べ事をしていて、 sincos() や sincosf() という正弦と余弦を同時に計算する関数があるのを知ったり。
確かに回転行列の中には sin(Θ)と cos(Θ)が含まれていて 最初に計算しますけれども。
GNUによる拡張らしいのですが、いつ頃から存在していたのだろう？
Emacsで「⛓(VS16無し)」と「⛓️(VS16有り)」で表示が切り替わらない件。
「⛓(u+26d3;chains)」の すぐ近くの「⛑(u+26d1;rescue worker’s helmet)」や
「⛩(u+26e9;shinto shrine)」は
「⛑(VS16無し)」と「⛑️(VS16有り)」や「⛩(VS16無し)」と「⛩️(VS16有り)」は
表示が切り替わります。なぜ ⛓ だけが切り替わらないのかやっぱり謎🤔。
VS16の有無でフォントを切り替える処理はどこで行なわれているのだろうか？
Cygwinパッケージのオリジナルの 29.4 emacs-w32バイナリで確認してみたところ、
「⛓(VS16無し)」と「⛓️(VS16有り)」の表示が切り替わる事が判ったり。
そして、パッチ版(harfbuzzが使える)の Unicode15.0までの対応としている emacs-w32バイナリでも
「⛓(VS16無し)」と「⛓️(VS16有り)」の表示が切り替わりました。
| emacs | 対応Unicode | Backend | 結果 | 備考 | |-------------------------+-------------+-----------+------------+--------------------------------------------------------------------------| | original 29.4 emacs-w32 | 15.0 | uniscribe | 切り替えOK | | | パッチ版 29.4 emacs-w32 | 15.0 | harfbuzz | 切り替えOK | | | パッチ版 29.4 emacs-w32 | 15.1 | harfbuzz | 切り替えNG | admin/unidata/emoji-zwj-sequences.txtを手動で unicode 15.1対応に入れ替え | | パッチ版 30.0.60 emacs | 15.1 | harfbuzz | 切り替えNG | | | パッチ版 30.0.60 emacs | 15.1 | uniscribe | 切り替えNG | ./src/emacs -xrm Emacs.fontBackend:uniscribe で起動 |