世界を動かす技術を、日本語で。

Babelがあるからこそ、Emacsでブログを書き続ける

概要

  • Org mode の標準パブリッシュ機能でブログ記事をHTML化している現状
  • シンプルな静的サイトジェネレーターへの憧れと現実のギャップ
  • Orgのエクスポート処理の複雑さと理解しきれない苦悩
  • Babel によるコード実行・出力埋め込み機能の圧倒的利便性
  • シンプル化の誘惑とBabel機能の再現困難さによる葛藤

Org modeと静的サイトジェネレーターへの憧れ

  • 他人の シンプルな静的サイト生成環境 への羨望
  • 自作すれば 2,000行程度 で理解しやすく、拡張性や共有性にも優れる可能性
  • 現実は Org mode で記事執筆・標準パブリッシュ関数によるHTML出力運用

Orgパブリッシュ処理の複雑さと理解困難

  • Orgのパブリッシュ処理は 脆弱さ もあるが、何より仕組みが理解できていない
  • org-publish-current-file コマンド実行時の内部処理が不明
  • Lispコードをトレースすれば分かるが、実際のエクスポート関連コードは膨大
    • ox-html.el (HTMLエクスポート)だけで約5,000行
    • ox-publish.el/ox.el (エクスポートフレームワーク)で約8,000行
    • org-element.el (パース処理)で約9,000行
    • 合計 2万行超 の複雑さ

Babel機能の圧倒的魅力

  • 他の軽量マークアップ(MarkdownやReSTなど)も コードブロック埋め込み は可能
  • Org+Babel はエクスポート時に コード実行・出力埋め込み が可能
    • 出力が表や画像でもそのまま記事に反映
    • セッション対応 でコード定義の再利用も可能
    • マークアップからコードへの変数注入、逆も可能
  • JavaScriptシンタックスハイライト 不要(Orgがインラインスタイル生成)
  • 多数言語対応(筆者は主に R でプロット描画に利用)
  • データ・図・テキスト を同時に下書きし、相互調整しながら執筆できる利便性
  • 一度体験すると 手放せない 機能

シンプル化の誘惑と現実のジレンマ

  • 2,000行の静的サイトジェネレーター なら週末プロジェクトで実現可能
  • しかし Babelの機能再現 は、時間の限られた筆者には 数ヶ月規模の大仕事
  • 結果として現状維持、複雑なワークフローを「自分で自分を責めつつ」使い続ける選択

参考リンク

Hackerたちの意見

へへ。俺はブログの投稿をorgモードで書いてて、Pelicanにそれを読ませる方法があるんだ。でも、エクスポート時にBabelソースブロックを実行するのはサポートしてないから、その機能をパッケージに追加した方がいいかも。[1]https://getpelican.com/ [2]https://blog.nawaz.org/posts/2022/Dec/reintroducing-opel-put...

Pelicanは見たことなかったけど、Zolaを使ったよ。個人的には、バイナリディストリビューションの方がpipやuv、npm、yarnのアプローチよりずっとクリーンだと思う。しかも速いし、RSS/Atomを自動でレンダリングできるしね。

Pelicanでブログを始めてから、Astroに移行したよ。Pelican(Pythonベースの静的サイトジェネレーター)は大体楽しんでたけど、テーマシステムがあまり好みじゃなかった。

俺も長い間同じような状況だったよ!2018年から自分のウェブサイトにorg-modeを使い始めて、最初はindex.orgをパスに追加するだけでソースが見れたんだけど、いつの間にか訳のわからない巨大なものになってしまった。Lispにあまり自信がなかったから、出力を自分のニーズに合わせて変更するために、数十のperl/sed/shスクリプトが混ざった恐ろしいものになっちゃった。でも、実際には、みんながいない孤独な週末に48時間くらいかけて、シンプルな静的サイトジェネレーターを作ったんだ。[2]同じファイルを使って、出力を完全に理解できるものにして、今では一番誇りに思ってるプロジェクトになったよ。他にもいろんなジェネレーターを試したけど(hugo、jekyll、rails、asciidoctor、org-publish、astro)、自分で作ると安定した基盤が得られる感じがする。君のウェブサイトも好きだよ!すごくクリーンだね。考えてるのは、(あまりジェネレーターに手を加えてないけど、俺は「完成」だと思ってる)ソースコードブロックの動的実行を追加することだ。[1] https://sandyuraz.com [2] https://github.com/thecsw/darkness

今はEmacsでブログ(https://lambdaland.org)を完全に書いてるよ。Hugoを使ってるけど、org-modeからmarkdownに変換するためにox-hugo [1]を使って、HugoがそれをHTMLに変換してくれる。これが気に入ってる点は、他のことも全部org-modeでやってるから、頭に合ってるんだ。脚注やマージンノートを綺麗に見せるための良いorg-modeツールもあるしね。ちょっと複雑だけど、もっとひどいのも見たことあるし。:-P [1]: https://ox-hugo.scripter.co/

Hugoもネイティブの.orgファイルサポートがあるみたいだね。ox-hugoはHugoのネイティブなorgファイル解析に対して機能を提供してるの?

org-babelは動くの?数式は動くの?

ox-hugoを使うことも考えたよ!自分の生活をプレーンテキストで整理しているから、すべてをorgファイルにまとめてるんだ。

参考までに、orgのHTMLエクスポートは約4000行のelispで、かなりモジュール化されてるよ。https://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox-html.... 公開フロントエンドはhttps://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox.elとhttps://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox-publi...

コードスニペットが比較的静的な出力を生成する場合はこれがうまくいくよ。最近はアニメーション、特にインタラクティブなものを作ることが多いんだ。例えば、https://akkartik.name/debugUIs.html を見てみて。自分の人生では、自動化ツールが特定の制限の中で生きることを強いるのに気づいたとき、もっと手動のツールに切り替えることが多かった。これらの制限に気づくのに10年かかることもあったよ。自動化は、1日に何度も同じことをする時には重要だけど、ブログ記事は数日に一度しか公開しないから、少し手間をかけてでも、もう少しコントロールを得て、マンネリから抜け出す価値があると思う。

私もorg modeでブログを書いてるんだけど、HTMLのブロックとしてエクスポートできるものは簡単に含められるよ。最近は、テキストの中にReactを使ったインタラクティブなチャートを入れてみたんだ。

自分でorg-modeの静的ジェネレーターを作ったよ:https://github.com/facundoolano/jorge 以前のemacsの設定よりも堅牢で、hugoよりもずっと軽いんだ。派手なbabel生成はないけど、正直それはあまり必要ないかな。

s3に最もシンプルなブログセットアップのおすすめは?条件は、JavaScriptゼロ、シンプルなCSS、ブログ用の機能は絶対に最小限で。理想は、Macのviでテキストファイルを開いて、思ったことをタイプして、保存して、スクリプトを実行するだけで、スタイルや日付、インデックスエントリーが自動で設定されることなんだ。

AstroやHugoみたいな静的サイトジェネレーターを、あらかじめ作られたブログテンプレートでセットアップできるよ。そうすれば、マークダウンファイルに投稿を書くだけで、ジェネレーターが残りを処理してくれる。カスタムテンプレートを作ることもできるし、デフォルトではJSや他のものはページに追加されないから、明示的に追加しない限り安心して使える。Astroの方が好きなんだけど、基本的にはHTMLに追加機能があるだけで、Hugoは別のテンプレート言語を使ってるからね。でも、どちらもほとんど同じだよ。GitHub PagesやCloudflare Pagesみたいなプラットフォームで、自動的に完全に無料でデプロイできるし、設定も簡単で、git pushのたびに新しいバージョンが自動でビルドされてデプロイされるよ。

Babelはすごく良さそうだね、試してみるべきだな。静的サイトにはPandocを使っていて、これを博士論文にも使ったよ。pandoc-plot[0]を作って、著者がやってるみたいに文書内の図を描画できるようにしたんだ。Matplotlibのplot-directive[1]に触発されてね。この機能は技術的な文章には必須だと思うけど、細かいところを正確にするのは難しいよね! [0]: https://github.com/LaurentRDC/pandoc-plot [1]: https://matplotlib.org/stable/api/sphinxext_plot_directive_a...

自分は長い間org modeを使っていて、babelもたくさん使ってたよ[1]。素晴らしい体験だったけど、市場はマークダウンを選んじゃったね。特定の機能のために時々org-modeに戻ることもあるし、babelの統合はまだ独自のレベルだけど、技術的にはマークダウンでも似たようなことができないわけじゃない。少し前にorg-babelのコードを使って、マークダウン用のコードフェンス評価器を作ったけど[2]、あまり必要性を感じてないんだ。だから、レポートをまとめたりエクスポートを実行したりする必要がないなら、テキストファイルの愛好家には1%の機能だと思うよ。[1] https://ess.r-project.org/ でのbabelの体験は、これまでの年月を経てもjupyterツールより優れていると感じてるよ。[2] https://github.com/whacked/emacs-markdown-babel

「市場」に合わせるのは、pandocを呼び出すだけでできるよ。必要なときは、同僚と共有するためにmarkdown、pdf、html、さらにはdocxにエクスポートしてる。org-modeで書くのが好きなのは、emacsの中で提供される完全なエコシステムのおかげ。でも、プレーンテキストとしては、markdownのsrcブロックが本当に恋しいな。

エンドツーエンドのワークフローを理解したいなら、「babelを除いて」でも構わないなら、emacsをヘッドレスデーモンとして実行して、emacsclientを使ってbabelに通すことができるよ。ちょっと洗練されてないけど、「ただの2,000行のコード」っていう完全な純粋さは欠けてるね。でも、その感覚はすでに抽象のレベルに基づいて線を引いてる。だから、emacsの使わない機能のバロックな大聖堂から離れることでワークフローが改善されるなら、自分のエンジンのシンプルさが欲しいなら、その2,000行の中のいくつかをbabelへの入出力のラッパーにすればいいんだ。結局のところ、こういうことは全部亀の背中の上にあるようなもので、少なくとも回路図を見つめて「これを全部半加算器で作れるかな?」って考えるまでのことなんだ。それ以上進むと、ちょっと高度な冶金を学ぶ必要があるかもしれないね。