昔の最近の出来事(2023.04)

2023/04/30

AM中に起床。

東京都コロナ感染者。新規は 976人。

先日Emacsは中国語でもEmacsと記すんだと思ったのですが、そういやWikipediaでもそう記されているのかしら? と思って見てみたり(中文 Emacs Wikipedia)。 ここでも Emacsやvi(Vim)はアルファベット表記みたいです。 「宏编辑器」が「マクロエディタ」の事だったり、「由理查·斯托曼」が「リチャード・ストールマン」だったりと 日本語では片仮名が充てられている単語も漢字になっていたりするようです。 漢字を充てる場合とアルファベット表記のままにするのとの境目は やっぱり判りません。 因みに、いわゆる「Emacs小指」は「Emacs小拇指」と記されているのですが、「拇指」だけだと「親指」を指すようで 「小拇指」は「小さい親指」とも訳せるようです。この為かページ翻訳すると「Emacs の親指」と翻訳されてしまうようです。 最短一致で翻訳すると何のことだが解らなくなるみたい。でもGoogle翻訳で訳すと 「日本語:小指 → 中国語:小指」 って出てきます。もしかして翻訳されていないという疑惑。 英語にしてみると「英語:little finger → 中国語:小指頭」って出てきて「小拇指」とはなりません。 しかし 「中国語:小拇指。小指頭 → 英語:little finger. little finger」と再変換するとどちらも little fingerとはなるようです。 一つの物に言い方がいくつかあるようで なんかムズっ って思ったりも。

2週間ほど前にFedoraを37にアップデートしたのですが、次のFedora38が出たようで 次のバージョンの案内が出るのが邪魔に感じたので 38にしてみました。 パッケージインストールしたanthyが先祖返りするの対応は同じく実施。壁紙が変わった以外の差はあまり判らず。 ただgccが 出たばかりの 13.1 になってます。gdcも DMDで言う所の 2.103に対応する感じになっているみたい。

Web散策していて 「THE PORTPIA SERIAL MURDER CASE」なるものを知ったり (参考記事)。 記事に「AI搭載版『ポートピア連続殺人事件』」と記されていてなんのこっちゃ?と思ったのですが、 コマンド選択方式ではなくて キーボードから日本語入力して進めるらしい。 実際にやった事はありませんが遠い昔に聞いてた話だと PC88版はカタカナでコマンドを文字入力する方式だったらしい。 さておき、自然言語入力でコマンドを解釈してくれる以外の ストーリーなどはオリジナルと 変わらないみたい。 PC88版が発売された40年前だとキーボードで文章を入力できる人がかなり少なかったと思われるのですが、 現在はそういう感じでもなくなっている気がするので、キーボード入力が障壁になる事は無いのかも? 判りませんけど。オプションで音声認識にも対応しているようですが ポートピア連続殺人事件のWikipediaによると CUDA対応のGPUが必要になるらしい。えぇ....?😅

2023/04/29

昼過ぎ起床。寝すぎ。

東京都コロナ感染者。新規は 1915人。じわってるなぁ...

Emacs29のgitブランチで 中国語(簡体字)のチュートリアルファイルが更新されていたり。ほう...。 拙作ggltr(参考)を使いながらたまたま読んだ 「翻译(TRANSLATION)」の章に チュートリアルの中国語翻訳は 繁体字中国語版(TUTORIAL.zh)と 簡体字中国語版(TUTORIAL.cn) の二つがあって、元々は繁体字版の方を元に単語置換していたけれども、 繁体字中国語と簡体字中国語は単語の違いだけではなく表現や構文にも違いがあるので、 簡体字中国語として翻訳している というような事が記されているようでした。ほぅ...
また、日本語でも但し書きがあるような「フレームとウインドウの関係」についても チュートリアルでは「ウインドウとペイン(pane)」としているみたい。 そして 中国語の「Learning GNU Emacs(第2版)」では「ウインドウとフレーム」を「ウインドウとペイン」 と翻訳しているらしい。なかなか混乱しているなぁと思ったりも😅。 ただ思いますに frameとwindowは直訳しないと M-x で実行するコマンド名や関数名との対応関係が分からなくなりそう。 Google翻訳してみると対応する単語が無いという事では無さそうですが (英中翻訳「英語: frame, window, pane → 中国語繁体: 框架,窗口,窗格」、中英再翻訳「中国語: 框架,窗口,窗格 → 英語: frame, window, pane」、 中日翻訳「中国語: 框架,窗口,窗格 → 日本語: フレーム、窓、ペイン」で対応する単語はあるみたい)、 そのまま充てていない理由はよくわかりません。

今まで中国語の文書をちゃんと見る事が無かったのですが、中国語も句点は「。」なんだと思ったりも。 あと、Emacsは 「Emacs」と記されているなと思ったりも。日本語でも 翻訳不能な英単語は片仮名で「イーマックス」と記す 場合もあると思いますが、中国語はどうにかして漢字を充てる印象があった(それはそれでどうなるか見てみたいですが) ので アルファベット表記混じりの文章もアリなのかと今更ですが知りました。

Emacsの日本語チュートリアルファイルってUTF-8じゃないのか。

2023/04/28

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

東京都コロナ感染者。新規は 1613人。

gcc-13.1.0が出てたみたい。今年はほんの少し早い気が。

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

2023/04/27

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

東京都コロナ感染者。新規は 1663人。

もそもそと実験コーディング。うまくいくのだろうか....

2023/04/26

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

東京都コロナ感染者。新規は 1745人。

月面着陸失敗。そういや朝のTVニュースで話してなかったような?と思ったらそういう事になってたらしい。 アポロ11号の月面着陸もコンピュータの警報が出たり着陸場所をずらしたり燃料ギリギリだったり した訳ですが、50年以上経ってコンピュータや機械の類は進化していると考えられる今でも 楽勝では無いという事なのかしら。

gdcの組み込みバージョン。version()で指定できる組み込みキーワードがどこで設定されているのか判らなかったのですが、 どうやら gcc/config/i386/ の下に置かれるヘッダファイル等の中に EXTRA_TARGET_D_OS_VERSIONSというdefineや d_add_builtin_version()という関数で追加されているっぽいのが判りました。 まだソースコードを見ているだけですが、迂闊に「キーワードのWindows」を含まないようにすると色んな所がダメになるんじゃないか? という気がという気がしたりも。
先日の「version(Windows){Windows向けコード} else version(Posix){Posix準拠OS向けコード}」のように PosixとWindowsを同列に並べているのが変なのか?

version(Posix){
  version(Windows){
    version(Cygwin){
      ★ここがCygwin向け
    }else{
      ★どれでも無い
    }
  }else version(OS_A){
    ★OS_A向け
  }else version(OS_B){
    ★OS_B向け
  }else{
    ★どれでも無い
  }
}else{
  version(Windows){
    version(DigitalMars){
      ★DMD?
    }else version(MinGW){
      ★ここがMinGW向け
    }else{
      ★どれでも無い
    }
  }else version(OS_X){
    ★OS_X向け
  }else version(OS_Y){
    ★OS_Y向け
  }else{
    ★どれでも無い
  }
}

Windowsの様に OSカテゴリの下に MinGWやCygwin(非PosixとPosix準拠)といった異なる複数のシステムがあり得るってのが、 他のOSには無いかも知れません。 あと、version()は OR式が書けないので 内容が同じ versionの組み合わせを束ねる事ができません。 この為、組み合わせ毎に いちいち全部書かなくてはならないという感じにもなりそう。

2023/04/25

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

東京都コロナ感染者。新規は 1909人。くすぶっているなぁ。

gdc-11.3.0を Cygwinネイティブビルドしてみる件。 libphobosのビルドに失敗していますが、Cygwinのケースが全然入っていない為、 「static assert(false, "Unsupported platform");」というアサーションに引っかかりまくります。 対応できそうか少し試してみていて困った事に気づいたり。 Cygwinでビルドしたgdcコンパイラは、「version (Windows)」と「version (Posix)」と「version (Cygwin)」が コンディションとして含まれているようなのですが、libphobosのコードには 「version(Windows){Windows向けコード} else version(Posix){Posix準拠OS向けコード}」といった 条件分岐がそこら中に散りばめられている為、Cygwinの場合は どちらかというと Posixとして対応する必要が あると考えているのですが Windowsも含まれてしまっている為、前述の条件では Windows向けコードが 生きてしまいます。中には PosixとWindowsが同時に含まれていることが無い前提のコードもあり、 対応が絶望的に面倒臭くなっているように思いました。そこで、Cygwinの場合は 「version (Posix)」と「version (Cygwin)」だけを含んで「version (Windows)」を含まないようにできないか? と考えたのですが、プラットフォームに対応したコンディションをコンパイラのどこで埋め込んでいるのかが判らず。 あれぇ?🤔

Emacs29のgitブランチをpullしてみたら、何やらペルシャ語のチュートリアルファイルが追加されていました。 ところで、ペルシャ語というのはGoogle翻訳で言語判定して判ったのですが、 チュートリアルファイルは etc/tutorials/TUTORIAL.fa というファイルが追加されていて、 ロケールの言語コードで faは ペルシャ語の事らしい(参考ページ)。ほぅ...。
あと etc/HELLOファイルに「Mongolian Traditional」が追加されてました。モンゴル文字らしいのですが 表示できなかったのでNotoフォントを入れて一応表示できてみたり。 ただ、モンゴル文字のWikipediaによると 縦書きされるものっぽい。また翻訳も出来なかったのでEmacsでの表示が合っているのかもよく判らず😓。

2023/04/24

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

東京都コロナ感染者。新規は 571人。

調べ事して終了。

2023/04/23

昼前起床。

掃除したり洗濯したり。

東京都コロナ感染者。新規は 1138人。

minttyに表示された文字列をマウスのダブルクリックで選択する事があるのですが、いつの頃からか 「~(チルダ)」が選択の対象にならなくなっていたり。例えばターミナル操作でディレクトリを潜った時、 そのディレクトリパスの中のファイルをEmacsで編集する際、例えば 「~/path/to/dir/」 がプロンプトに 表示されているのをコピーして Emacsの「C-x C-f」後のミニバッファ編集で貼り付けるという事 をやっていたのですが、「~」が含まれなくなったのでそのまま貼り付けると「そんなディレクトリは無い」 となってしまいます。微妙に面倒臭くなってます。

gdcが本家のgccに取り込まれてから随分経つのですが (過去のメモ)、それ以降はMinGWの対応は行われていないようだったのもあって 自分でコンパイルする事はありませんでした。 Windows用は DMDとldc2に移行したのでコンパイル環境自体は困ってはいないものの (いや、外部ライブラリのビルドが超絶面倒過ぎて更新できていないという問題はありますが)、Emacsのflymake向けには 現在も最後にビルドできたMinGWのgdcクロスコンパイラを使用しています。flymakeもDMDやldc2に移行できないものかと思ったのですが、 出力されるフォーマットが全然違う為か、メッセージをちょっとしたフィルターで似せてもうまく動かす事が できませんでした。という訳で、文法チェックの為だけに gdcコンパイラ本体を MinGWクロスもしくはCygwin向けに コンパイルできないかなぁ?と思い最新の gcc-12.2.0の コンパイルを行ってみる事にしました。ここまでは前置き。

すっかりビルド手順を忘れてしまっていますが、パッチ時代のgdcを Cygwinで MinGWクロスコンパイラをビルドする 手順で gcc-12.2.0 のビルドを試みたところ configure実行でエラー。 全く認識していなかったのですが、12.2.0では gdcのフロントエンドが D言語版になってしまっていて、 ネイティブでgdcコンパイラが動作しないとビルドできない(いわゆるブートストラップできない状態)になっているようでした。 一つ前の 11.3.0では まだ C言語(あれ?C++じゃなかったっけ?😓)で書かれていたので 11.3.0の方でまずは試す事に。

11.3.0では 「--enable-languages=c,c++,d」でも configureが通ったので make開始。....あれ?エラー無くビルドできてしまったような? ビルドされたディレクトリを確認してみたのですが、gdcクロスコンパイラはビルド出来ているようですが、 libphobosがビルドされていませんでした。 configure.acを眺めてみたところクロスコンパイルではビルド対象から外されているっぽいのですが、 「--enable-libphobos」ってconfigureオプションを使えばビルドされるかも?という感じだったので再度実行。 ここで色々コンパイルエラーになるのだろう。という訳でしばらく待ち。

... libphobosのビルドが開始されてるような .... ん?あれ?エラーせずに終わったよ? ディレクトリを確かめてみると一応 ライブラリはできているようです。本当かなぁ?と思いつつ make install。 HelloWorld的なコードをコンパイル....通った.....実行.....動いた....マジでか!?😲

$ x86_64-w64-mingw32-gdc.exe -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gcc-11.3_gdc_mingwcross/libexec/gcc/x86_64-w64-mingw32/11.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-11.3.0/configure --with-pkgversion=gdc-11.3 --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-w64-mingw32 --enable-languages=c,c++,d --prefix=/usr/local/gcc-11.3_gdc_mingwcross --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --enable-threads=win32 --disable-win32-registry --enable-target-optspace --disable-nls --disable-bootstrap --disable-shared --disable-multilib --enable-long-long --enable-libphobos
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (gdc-11.3)

$ cat hello.d
import std.stdio;
import std.string;

class Hello
{
  this(){
  }

  void print(){
    writeln("Hello D world.");
  }
}

void main()
{
  auto hello=new Hello();
  hello.print();

  return;
}

$ x86_64-w64-mingw32-gdc.exe -O2 hello.d

$ ./a.exe
Hello D world.

$ cat iam.d
import std.stdio;
import std.string ;
import std.compiler;

int main()
{
  writef("%s %s %s.%03d (D%s)\n",name,vendor,version_major,version_minor,D_major) ;
  version( GNU     ) writef("I am GNU\n"    ) ;
  version( LDC     ) writef("I am LDC\n"    ) ;
  version( DigitalMars   ) writef("I am DMD\n"    ) ;
  version( Unix    ) writef("I am Unix\n"   ) ;
  version( linux   ) writef("I am linux\n"  ) ;
  version( Windows ) writef("I am Windows\n") ;
  version( MinGW   ) writef("I am MinGW\n"  ) ;
  version( MinGW32 ) writef("I am MinGW32\n") ;
  version( MinGW64 ) writef("I am MinGW64\n") ;
  version( cygwin  ) writef("I am cygwin\n" ) ;
  version( Win32   ) writef("I am Win32\n"  ) ;
  version( Win64   ) writef("I am Win64\n"  ) ;
  version( Posix   ) writef("I am Posix\n"  ) ;
  version( X86     ) writef("I am X86\n"    ) ;
  version( X86_64  ) writef("I am X86_64\n" ) ;
  version( ARM_SoftFloat ) writef("I am ARM_SoftFloat\n" ) ;
  version( ARM     ) writef("I am ARM\n"    ) ;
  version( PPC     ) writef("I am PPC\n"    ) ;
  version( PPC64   ) writef("I am PPC64\n"  ) ;
  version( PPC_SoftFloat ) writef("I am PPC_SoftFloat\n" ) ;
  version( PPC_HardFloat ) writef("I am PPC_HardFloat\n" ) ;

  return(0) ;
}

$ x86_64-w64-mingw32-gdc.exe -O2 iam.d

$ ./a.exe
GNU D gnu 2.076 (D2)
I am GNU
I am Windows
I am MinGW
I am Win64
I am X86_64


手持ちのウインドウを開くだけの極単純なGUIアプリもビルド&実行できました。 gcc-11.1.0 は2021年の4月のリリース(gcc-11.3.0は2022年の4月ですが)なので、DMDのベースは2.076と 少し古いものの、何の手も入れずにビルドするだけで使えるようになっていたとは!! ありがたい事です。

そして本題。12.2.0をビルドする為に 11.3.0 のgdcを Cygwinネイティブでビルドできるか? 結果は失敗。libdruntimeのコンパイルでエラー。 でも、標準Cライブラリをバインディングする libdruntime/core/stdc/* 辺りのコードに Cygwinだった場合の定義が無いのが大勢を占めている予感。 何かしら足せば通せるかも知れません。判りませんけど😅。 ただ、漠然と MinGWがイケるんならCygwinもイケるんじゃないの?とは思ったりも。

2023/04/22

昼過ぎ起床。

東京都コロナ感染者。新規は 1477人。

テストでEmacsをビルドするとき、うっかり -jオプション無しで makeを実行してしまったのですが、 まぁ適当な時間で終わるだろうとほったらかしたら全然終わらないのでいったん止めたり。 実際どれくらいかかるのか確認してみたところ 3.6倍くらい時間がかかるって所でした。

time make -j9 time make
real    2m37.786s
user    11m13.253s
sys     2m13.404s
real    8m59.671s
user    7m13.958s
sys     1m26.519s

実測してみたら3.6倍だったので「全然終わらない」という時間でもないと思い直したのですが、 -j指定実行での感覚に慣れていると2倍以上かかるのは待てない感じになっているのかも知れません😓

そういえば、前日 Emacsでの アニメーションGIFの動作を調べていて、Emacs29でサポートされるWebPは アニメーションにも対応しているというのを知りました。
GIMPでアニメーションWebPを生成できるというのを知ったので試してみました。

アニメーションWebPテスト

Web検索すると表示できないブラウザ対策の為に pictureタグ を使って代替画像を表示する例があるようですが、 現在は(?)imgタグにそのまま指定しても大丈夫っぽいです。 320x180のサイズで 256フレームのファイルですが 約7.0MiBくらいあるので、 H.264の動画に比べると大分大きいです(試しにH.264のmp4にしてみたら3.8倍くらいWebPの方が大きかった)。 ただ、透過などはWebPでしか使えないと思いますので用途に応じて使い分ける感じかも知れません。 因みにPOV-Rayでシーンファイルをレンダリングしたものをアニメーション化したのですが、 シーンファイルは以前4K動画の生成テストに借りた 「POVRay Short Code Contest - Round 3」 のeqstqh.povを流用しました。

鬼滅の刃の刀鍛冶の里編のアニメ。フジテレビで日曜の夜に放送されていますが、約1週遅れで 東京MXでも放送されています。フジテレビ版では次回予告がタイトルだけだなぁ?と思ったのですが、 東京MX版だと 次回予告前に大正コソコソ噂話のパートがあるなぁと思ったり。

2023/04/21

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

東京都コロナ感染者。新規は 1441人。

なにやらTwitterのページが表示できなくなっているみたい。 「アイスクリームも落ちていますし、Twitterも落ちています。散々な日ですね。失礼しました、冗談です。できる限り早く修正いたします。」 って軽いな😅。実際のところ何が起こっているかをGoogleで時間を絞って検索しても関係ありそうなページが 見当たらず。てか上位に出てくるのがツイートばかりで情報があったとしても見られないという感じ。 って書いてるうちに直ったみたい。レアなページだったのか?

調べ事。

2023/04/20

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

東京都コロナ感染者。新規は 1449人。

Web散策していてたまたま知った動画 「1986 [60fps] Salamander No shot Loop1 (Except Wall)」。 必要な場面以外はショットを撃たないというスーパープレイです。ラスボスは倒す必要があるという理由から 6面序盤で1機潰して ミサイルを取得しているのですが、隙間から狙ってもショットじゃ倒すことができないのかしら?と思ったりも。

ブラッキーの名称をスパイクに変更するという ツイート。 ブラッキーと言えば 個人的には 鈴木みそ氏の漫画「あんたっちゃぶる」を思い出します。 ブラッキーのWikipediaでも触れられているようです。

2023/04/19

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

東京都コロナ感染者。新規は 1514人。

native-image-apiでのアニメーションGIF対応。そもそも対応しているんだっけ?と思って調べてみました。 結論から言うと対応していないように見えます。src/w32image.cでは一応マルチフレームの対応は行われていて 指定したフレームを表示する事はできるようなのですが、アニメーションの方は src/image.cで animation_cacheなるものを用いて giflibや webpはアニメーションに対応しているようです。 この animation_cacheに対応する必要がありそうなのですが、native-image-apiでデコードした画像データを キャッシュする仕組みが無いみたい。なので、w32以外にも ns(macOS)や haikuは native-image-apiが 存在しているのですが、いずれもアニメーションには対応できていないと思われます。 真面目に対応するのは簡単ではなさそうなので、src/w32image.cは gifには対応していませんって事にして giflibを使用するワークアラウンドで対応する方向かなぁと思ってます。

そんな訳で1行コメントアウトして対応。多分大丈夫そう。

$ diff -u src/w32image.c.old  src/w32image.c
--- src/w32image.c.old  2023-04-10 21:28:45.425834500 +0900
+++ src/w32image.c      2023-04-19 23:22:37.087545100 +0900
@@ -287,7 +287,7 @@
     return false;
   if (!(EQ (type, Qjpeg)
        || EQ (type, Qpng)
-       || EQ (type, Qgif)
+/*     || EQ (type, Qgif) /* workaround; w32_load_image does not support animated GIFs. */
        || EQ (type, Qtiff)
        || EQ (type, Qbmp)
        || EQ (type, Qnative_image)))

御参考まで。

2023/04/18

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

東京都コロナ感染者。新規は 1696人。

何気にアニメーションGIFファイルをEmacsで表示してみたところ、アニメーションしないなぁ?というのに気づいたり。 確かアニメーションできてた記憶があったのと、バインドされているキー操作でフレームを進めたり戻したりできるので 先頭のフレームしか表示できないという訳でも無さそう。 少し調べてみたところ 組み込みのImageMagickで表示した場合はアニメーションするようですが、組み込みgif表示 だとアニメーションしないというのが判りました。もしやと思って「--with-native-image-api」としていたのを 「--without-native-image-api」にするとアニメーション表示できるようだったり。むむ。

2023/04/17

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

東京都コロナ感染者。新規は 474人。

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

2023/04/16

AM中に起床。

掃除したり洗濯したり。

東京都コロナ感染者。新規は 891人。

Emacs29.0.90でも一応 d-modeの動作を再度確認してみたのですがやっぱり動かなくなってます(参考)。 自作の言語モードに影響無いのだろうか?

Emacsでpythonコードの向けにデバッガを起動するのに「M-x pdb」を使えば良いらしいのですが、 ブレークポイントを設定しても全然止まっている気配が無いのは気のせいか?🤔

2023/04/15

AM中に起床。

東京都コロナ感染者。新規は 1197人。

リモートマシン(VMware上のFedora)の中に置かれた pythonコードのファイルを ローカルホストのEmacsからTRAMP経由で 編集したのですが、flymake-pythonってリモートファイルはチェックしてくれないのだなぁ?と思ったりも。 リモートマシンにflake8が入っていなかったので入れてみたのですが反応せず。 まぁ、リモートのファイルをローカル環境でチェックするのも違う気がするので ローカルホストのEmacs上のリモートファイル名が例えば「/scp:user@host:/pathto/foo.py」だった場合は、 「ssh user@host 'flake8 /pathto/foo.py'」みたいな感じでflake8をリモート実行する ような事を考える必要があるのかも?とは思ったりも。

2023/04/14

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

東京都コロナ感染者。新規は 1215人。

Fedoraを37にアップデートしてみたり。毎度の事ですがパッケージインストールしたanthyが先祖返りするので /usr/share/emacs/site-lisp/anthy/anthy.elを直したのに置き換える必要があります。 そういや Emacs29向けの修正を行ってた(参考)のを思い出したのでそちらに置き換え。 因みに 37でもImageMagickは 6系のままみたい。何故 7系にならないのかは不明。

2023/04/13

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

東京都コロナ感染者。新規は 1181人。

Emacs-29.0.90でビルドのテスト。 パッチ無しだとバグったままだったり有効にできない機能が多いなぁ?と改めて思ったりも。

2023/04/12

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

東京都コロナ感染者。新規は 1334人。

WindowsアップデートのついでにCygwinパッケージをアップデートしたのですが、新しいbashが壊れているせいか インストール中にポストプロセスのスクリプト実行に失敗したり。仕方ないのでbashは一つ前のバージョンに戻した ところ問題無し。Cygwin本体は emacs-w32でのSVG描画を使用するアプリでメモリリークが発生している問題が解消してないので 3.3.6をキープという感じで。

なんか Edgeブラウザのスクロールバーが変わってるな?と思ったのですが前からこうだっけ?と思い直したりも。

Magitのアップデートを行ってみたり。去年アップデートしたのですが、 Emacs29と組み合わせるとtransientってパッケージがEmacs29に同梱されているものとelpaでインストールされたものとが 衝突してエラーになっていました(参考)。 新しいmagitにしてみたところ、transientの衝突の問題は解消したみたいなので、強制的にelpa側を読み込んでいた ワークアラウンドを外して大丈夫そうな感じに。
因みに、Emacs29に同梱される方の transientが使えないと、例えば emoji-insertコマンド(C-x 8 e e)がうまく動きませんでした。 でもこれで 絵文字の入力手段が一つ復活しました🙂

2023/04/11

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

東京都コロナ感染者。新規は 1490人。

Pouetの方にRevision 2023の結果が出てました。 毎度の事ですがエントリ作品数が多いです。ゆっくり観よう。

2023/04/10

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

東京都コロナ感染者。新規は 458人。

Emacs 29.0.90が来た模様(Emacs 29.0.90 pretest is available)。

29.0.60から IME/他を含めてパッチを作成。29.0.90にいきなり当ててみたのですがリジェクトはされずビルドも成功。 起動もひとまず問題無さそう。ちょろっと試した範囲ではいきなりSegfaultするような事も無さげ。しばらくテストしてみよう。

CygwinのMLを眺めていたら bzip3なるパッケージが来ているのを知ったり。ん?bzip3? GitHubにリポジトリがあるようです(こちら)。 1年くらい前に最初のコミットが行われたようです。Web検索しても日本語で触れているページがほぼ無い感じみたい。 ただ、bzip2の時にはついに付くことの無かった gzipやxzで言う所の -l, --list オプションは bzip3でも付いていないみたい。

2023/04/09

AM中に起床。

東京都コロナ感染者。新規は 956人。

たまたま見たTweetで思った難しい日本語。 「○○というデマが流れています。これは嘘です」という文で、「"○○というデマ"が嘘 なので○○は本当の事」 なのか「○○はデマ(==嘘)」なのかがよく判らない。後者の意図があって 強調のつもりで二回繰り返すつもりが言い方を変えた為に 二重否定に読めなくもないという感じかも。

今更ですがD言語の動的配列に .capacityというプロパティがあるのを知りました。 例えば「int[]」配列として「new int[1500]」で割り当てた場合、.lengthは1500となりますが、.capacityは2043となってました。 差分となる 2043-1500=543要素は予備となっていて、例えば .lengthを1500から1600に増やしても再割り当て無しに増やせるという事らしい。 .lengthを減らすと .capacityが0になったりするですが、.ptrは変化しなかったりするので挙動はイマイチよく判っていませんが。

2023/04/08

AM中に起床。

掃除したり。

東京都コロナ感染者。新規は 1261人。

陸自ヘリ行方不明。今の時代に見つけられないなんて事あるのだろうか?不思議。

Twitterのソースコードが一部公開されたらしい(twitter/the-algorithm)。 この部分については半分は Scalaで書かれているみたい。ほぅ...

そういやRevision 2023が始まっているのをすっかり忘れてました。 Revisionのタイムテーブルはローカル時間で表示 してくれるので便利です。メインはどれも日本時間の深夜~早朝なので 後日Pouetから動画を観る感じかも知れません。

2023/04/07

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

東京都コロナ感染者。新規は 1133人。

Emacs29。gitブランチは少し落ち着いてきた? まだ29.0.90が出そうな気配はありませんが。

2023/04/06

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

東京都コロナ感染者。新規は 1109人。

ムツゴロウさん死去。87歳との事ですがもっとおじいちゃんかと思ってました。

アーケードアーカイブスに「REZON」ってゲームが来ていたのですが、存在自体を初めて知りました (参考Wikipedia)。ほぅ...。

2023/04/05

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

東京都コロナ感染者。新規は 1204人。横ばいだなぁ...

調べ事。

2023/04/04

本日まで休業。AM中に起床。

東京都コロナ感染者。新規は 1357人。

何気にEmacsの GUIのメニューを見ていたら、「File→New Window on Right」がどこにもバインドされていないなぁ? というのに気づいたり。-Qで立ち上げると「C-x 3」のバインドが併記されたので、あれ?うちの設定?と 思って調べてみたら「(global-set-key "\C-x3" 'split-window-horizontally)」って設定を明示していました。 なぜ明示していたのか記憶に無いのですが、いつの間にか split-window-horizontally の名前が変わっていたようです。 gitでログを遡ってみたところ、 今から約12年くらい前に「Move window resize code from window.c to window.el.」という変更でリネームされたようです。 この時点では split-window-horizontally から split-window-side-by-side になっていたようですが、 約5ヵ月後に「Rename split-window-{above-each-other|split-window-side-by-side}」でもう一度リネームされて 現在の split-window-right になったようです。
元々の horizontally でも良いんじゃないの?とも思ったのですが、 例えばEmacsでは 水平軸を分割するので縦割り(==左右に分割) という意味ですが、screenコマンドやvimでは 垂直(vertical)軸に沿って分割するので縦割り という意味なので、解釈によって結果が逆になるという vertical/horizontal どっちがどっち問題があるかもな?と思い直したりも。 あとは GUIメニューのラベルに長い文字列を使うのが見た目の問題で良くないので短くしたのが今の結果だったりするのかしら? とも想像したりも。

2023/04/03

本日休業。昼前起床。寝すぎ。

掃除したり。

東京都コロナ感染者。新規は 420人。

観るのが追い付いていなかった録画を消化したりしてぐうたら過ごしたり。

4月2日付けでSAI2の新しいのが来ていました。おつかれさまです。いくつかのバグ修正と仕様変更が行われているようです。

2023/04/02

AM中に起床。

東京都コロナ感染者。新規は 789人。

Emacsのinfoコマンドでinfoを眺めていたのですが、タイトルのフォントフェイスが違うときがあるなぁ? というのに今更ですが気づきました。

Emacsのinfoのタイトルフェイスが異なる

どうやらシングルクオートやダブルクオートが「’」(U+2019)や「“」(U+201c)といった ユニコード文字で表示されている場合に、画像の上側ウインドウのように本文と同じフェイスで表示されるようです。
lisp/info.el内の 関数Info-fontify-node で string-widthを使ってタイトル文字列とASCII文字で表現されるアンダーライン が同じ長さだったらタイトルフォントフェイスを使うようになっているみたいですが、string-widthは表示される時の文字幅が 返るようなので、全角フォントで表示されてしまうとタイトル文字列の長さとアンダーラインの長さ一致しない為、 結果、本文と同じフェイスで表示されるという感じみたい。 string-width を lengthに変えればひとまず対応できそうですが、 本当に良いか?はよく確認する必要はあるかも?

Emacsのinfoのタイトルフェイスを直してみた

現在のコードになったのは「(Info-fontify-node): Use `string-width' for fontifying underlined titles.」からのようですが、 string-widthを使う前は自力で長さ計算をしていたようです。 関数lengthだとマズい事があったからstring-widthを使うようになったみたいな感じでも無さそうなので大丈夫かも知れません。
....大丈夫と思ったけど、日本語のInfoの場合にダメになります😓。 フォントの文字幅問題なのでやりよう無い感じがしなくもありません....🤔

フォントを「PlemolJP Console HS」にして以下のようなテストコードで試してみたのですが、 見た目は文字幅1(が4個)にも関わらず、string-widthの結果は2(が4個)となるようです。

(string-width "‘’“”") ;;and press C-j
8

という訳でフォントの設定でどうにかなる話でもないようです。これは なかなか闇が深い....

どうやら -nw でも幅が2として返ってくるようです。という訳で特殊ケース対応っぽいですが、以下のような感じにしてみました。

--- lisp/info.el.orig	2023-03-13 05:22:41.000000000 +0900
+++ lisp/info.el	2023-04-02 21:38:45.215522600 +0900
@@ -4846,22 +4846,33 @@
           ;; underline has the same size as the text.  A typical
           ;; counter example is when a continuation "..." is alone
           ;; on a line.
-          (when (= (string-width (match-string 1))
-                   (string-width (match-string 2)))
-            (let* ((c (preceding-char))
-                   (face
-                    (cond ((= c ?*) 'info-title-1)
-                          ((= c ?=) 'info-title-2)
-                          ((= c ?-) 'info-title-3)
-                          (t        'info-title-4))))
-              (put-text-property (match-beginning 1) (match-end 1)
-                                 'font-lock-face face))
-            ;; This is a serious problem for trying to handle multiple
-            ;; frame types at once.  We want this text to be invisible
-            ;; on frames that can display the font above.
-            (when (display-multi-font-p)
-              (add-text-properties (1- (match-beginning 2)) (match-end 2)
-                                   '(invisible t front-sticky nil rear-nonsticky t))))))
+          (let ((title (match-string 1))
+                (uline (match-string 2))
+                (matchcount 0))
+            (dotimes (i (length title))
+              (dolist (c '(?‘ ?’ ?“ ?”))
+                (if (eq c (string-to-char (substring title i (+ i 1))))
+                    (setq matchcount (+ matchcount 1))
+                  )))
+            (when (or
+                   (= (string-width title)
+                      (+ matchcount (string-width uline)))
+                   (= (string-width title)
+                      (string-width uline)))
+              (let* ((c (preceding-char))
+                     (face
+                      (cond ((= c ?*) 'info-title-1)
+                            ((= c ?=) 'info-title-2)
+                            ((= c ?-) 'info-title-3)
+                            (t        'info-title-4))))
+                (put-text-property (match-beginning 1) (match-end 1)
+                                   'font-lock-face face))
+              ;; This is a serious problem for trying to handle multiple
+              ;; frame types at once.  We want this text to be invisible
+              ;; on frames that can display the font above.
+              (when (display-multi-font-p)
+                (add-text-properties (1- (match-beginning 2)) (match-end 2)
+                                     '(invisible t front-sticky nil rear-nonsticky t)))))))

       ;; Fontify cross references
       (goto-char (point-min))

タイトル文字列の中に「‘」「’」「“」「”」のいずれかが含まれる文字数で 補正した場合もタイトルと見なすように条件を増やした感じです。 これらの文字の string-width が1で返るロケールがあるのかは判りませんが、 元の条件は残っているので壊れる事にはならないだろうという感じです。

2023/04/01

昼前起床。

東京都コロナ感染者。新規は 991人。

ボストンダイナミクスのロボットの新しい動画(といっても2ヵ月前ですが) があるのを知ったり(Atlas Gets a Grip | Boston Dynamics)。 建設現場で工具を届けるという設定のようです。スゴイ事には違い無いのですが、 実際の現場じゃまだ任せられないかもなと思う所はあります。 いくつかはピタゴラスイッチ的に予めうまくいくように物を配置してあるという感じがします。 個人的には、荷物を放り投げるのはダメって所が一番引っかかったところかも知れません。 調子に乗って怪我するタイプ感があります。 多分、見ていてあぶなっかしい感じがしなくなるにはまだ時間がかかるんじゃないかなぁ? とは思ったりも。例えばちゃんと命綱を付けて絡まないように捌いて それで作業もこなして...みたいな所まで含めると かなり難しいんじゃないかと思います。

すっかり放置していた Emacs29での image-cropモードで水色の横線が入る件(最後のメモ)。 -Q起動だと線が入らないのは判っていた(過去のメモ)ので テスト用に.emacsをコメントアウトで潰しながら絞り込んでみたところ、 どうやらwhitespace-modeが有効になっていると こちらの感じで水色の横線が入るという事が判明。 find-file-hooksを使って ファイルを読み込んだ時にwhitespace-modeを有効にしているのですが、 image-modeそのものでは特に線が入る事は無くて、image-cropの編集状態になると線が入るという謎な感じになるようです。 困ったのが対応方法で、見かけ上 find-file-hooks が一番最後に有効になっていて、image-modeのhookで 相殺できない感じになってます。うーむ🤔。 結局、find-file-hooksで実行する自前関数の中でメジャーモードを示す変数major-modeの内容によって whitespace-modeにするか否かをフィルターするようにして対応してみました。


TOP PREV