TeX で JSON してる先行事例ならこちら💁♂️
https://note.golden-lucky.net/2016/12/jsontex.html https://twitter.com/a_175/status/1352785542224646144
優勝罰金n千億円のチキンレース🐔 https://twitter.com/komorin95/status/1352891171962384385
字句解析の入口……? 「沼の入口🤮」の間違いでは🤔
(TeX/LaTeX の字句解析は,“ちゃんと” やろうとしたらもう完全に地獄ですよ) https://twitter.com/hirano_everyday/status/1352845204458332162
でもコレクション単位でインストールして云々ってやつは,ある程度 TeX エコシステムに詳しくないと使いこなせない中級以上向けの機能だし,そのレベルの人はもう「TeX Live フルスキーム全部入れればいいじゃん.入らないなら入るディスクを買えばいいじゃん」ってなる人たちだから……
いや現在の TeX Live の考えは完全にこれで,細かく依存解決はしないけど「コレクション」という単位で,特定機能・分野ごとの依存関係の “閉じた” パッケージがまとめられていて,その単位でインストールができる.
BT: https://mathtod.online/@cmplstofB/105602970115703653
まあ「要するに homebrew-core みたいな感じ」で伝わる人もいるかもしれないけど,あの方式の管理が成立するほど TeX 界隈にリソースがあるかといえば,自分もかなり懐疑的.
というか「依存パッケージを CTAN 登録時に全列挙する」という文化がない状況では,集合知により依存情報を収集するしかないと思うけど,それって1回やったらそれで終わりというわけではなくて,未来永劫その DB をディストリビュータ側で管理しないといけないので,膨大なリソースが必要になる.
TeX Live のパッケージマネージャで依存解決可能なやつ,自分が tlmgr を Rust で書き直す服案を本気で実行する気になった際には同時に実装するよ(優先度めちゃめちゃ低いので一生やらなそう) https://twitter.com/wtsnjp/status/1352670845194264576
TeX Live の偉い人たちを全員説得するのは結構難しい可能性があると(自分の経験からも)思いますが,原理的には TeX Live とは別の派生ディストリビューションとして作る分には誰でもできるはずなのに,誰もやらないわけです.結局それができるレベルのユーザはそんなに困ってないのだと思います.
個人的にはもう「full scheme が前提」とするには肥大化し過ぎてるので,完璧でなくとも best of our knowledge で依存関係を解決する方式にした方がいいと思っています.ただパワーユーザほど TeX Live にディスク容量を取られるのを厭わないので,誰も実務に取り掛からないのではないかなぁと.
単純に膨大な古いパッケージ(すでにオリジナル作者やメンテナと連絡が付かない)の依存関係を今さら正確に調査して把握するのが不可能だから,だと理解しています. https://twitter.com/bd_gfngfn/status/1352642321649606658
TeX から Win32 API を呼び出してる人がいたけど,それもやりやすくなったりするのかな(たぶんしない) https://forest.watch.impress.co.jp/docs/news/1301910.html
Windows 初心者過ぎて,買った初日に起動できなくした(厳密には唯一の管理者アカウントにログインできなくなった)のが個人的最高記録(何の?)
https://twitter.com/wtsnjp/status/1058970057303240705
ブートローダの設定をふっとばして PC を通常起動できなくして焦るやつとか,誰もが人生で一度はやるやつでしょ?
※主語が(ry https://twitter.com/wtsnjp/status/1037216955005120512
5トゥートぐらい読むと何となくわかる