Notices by きゅーけー (tojoqk@mastodon.tojo.tokyo), page 221

最新の Guile だと SRFI-1 の map をエクスポートするのはあんまりいい考えとは言えなそうだし、Guile 2.2 のサポートに留まるのでいいかな……。単にテストの問題とは言えない根の深い問題に見える。

うう、guile-cv はどうして (srfi srfi-1) を re-export-public-interface しているんだ……。それは困るよ……。

Guile-cv、テストが通らないだけで Guile 3.0 でもたぶん普通に動くな……。悩ましい。

Guix にはパッケージを整備する戦力が足りてない気がする。

自慢気に電子メモパッドから線を抽出するやつを紹介したいのでまず、 guile-cv が簡単にインストールできる状態でないといけない。

guile-cv が guix で簡単にインストールできないと、人に guix を使って簡単にインストールできるよって説明できなくなっちゃうから困るのだ。ブログにも書きにくい。

メールでパッチを送信することに慣れてしまったことに起因する謎の感覚なんだけど、GNU Guix のメーリングリストでパッチを送れるの、特定のサービス(GitHubとかGitLabとか)の使用を強要しないのでむしろいい気がしてきた。

また、2.2 を追加するだけのパッチを送ってしまった。誰も guile-cv を使っていないのだろうか……。なんか 2020 年から 2021 年まで開発した感でてるけど、2.2 を2回追加しただけなんだよなー。https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47659

スマートってついてるやつむしろだいたいスマートじゃな気がしてきた。

スマートな監獄

なるほど

スマート引用符ほどスマートを自称するスマートじゃないものは他にあるのだろうか。

実は REPL で開発する必要はないという真理と向き合って、geiser-repl から一旦離れよう。

guile-cv、Emacs の geiser で対話的に開発できるのはウリだと思うんだけど、ミスったときに Emacs が死ぬので実質 REPL では開発できないなー。

Guile では出力を truncate したくないというその気持ちはよくわかった。Emacs のために truncate するの微妙だしな。

5回くらい Emacs が死んでもう Emacs で guile-cv のコードは実行したくなくなったもん。

うーん、やっぱ Emacs を直した方がベターだよな。。。

Emacs が長い行を受けると死ぬ問題は十分他のエディタを検討する理由になる。Emacs の方直すのはつらそう。。。

この理由で Guile の開発で Emacs を使うの避けるのはざんねんすぎるよなぁ

Guile を直すよりも Emacs を直す方が正しいという指摘には笑わざるを得なかった。実際 Emacs が悪いと思う。