ｱﾝﾖﾖｲﾖのメールクライアントは FairEmail がおすすめ、とても満足だったので課金機能解放したくらいにはおすすめ

このアカウントは、notestockで公開設定になっていません。

n575

削ってしまったら a575 なんだよな (?)

悩ましい (???)

n575: natural 575 (意図せぬ575)
a575: artificial 575 (意図して作られた575)
b575: bad split 575 (変なところで区切って強引に575フォーマットに仕立てあげられた偽りの575)

変なとこ
ろで区切られた
575

みたいなのが #b575 です

以前通り過ぎたマンガ大賞

先に文脈としてパラダイムを指定しないと何も言えなそう

本家ﾜｻﾋﾞ東京リージョンマンなので円安は痛いよ

なんならサーバも Vultr なのでやっぱり痛いよ

スーパーサイ夜勤

https://mastodon.cardina1.red/@lo48576/108986864977208134

堀江晶太ァあああ！！！！！ つってヘビロテリストに突っ込んである

天才なので進捗が続出し、あとはタグ打ってリリースするだけの段階まで来た。

ところで外が明るいな？

風呂入って寝るか……

？？？「将軍様は半導体を屏風から追い出してください」

赤ちゃんの泣きやみと寝かしつけの科学 | 理化学研究所
https://www.riken.jp/press/2022/20220914_1/

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

構文が混乱してきて大変なことになり最終的に XML へ (?)

私のブログは今のところ完全独自マークアップや DocBook + 拡張タグのステージを経て HTML + 拡張タグになっている

AsciiDoc なぁ、スキーマが DocBook のサブセットなのは良いのだが、マークアップでない言語全般の弱点である「ネストの表現力が弱い」の問題が解決できなくてつらかった

べつにこれは AsciiDoc 特有の弱点ではなく、むしろ同類の中ではかなりよくやっていると思うけど

reST は良し悪し以前に3文字インデントがキモくてな……

いや合理的ではあると思うけど、他のフォーマットと混ぜるといろいろ汚くなりそう (混ぜるな)

toml に markdown を突っ込んでその中にコードブロックを書いたりするようなことをしたくなることがあるので

自由な実装が存在しなそうなことに目をつぶればね……

ｵﾋｽｽｲｰﾄ系はメタデータ隠されすぎて険しい

markdown も事実上の “標準” であるところの CommonMark にはテーブル記法が無いのではなかったか

あと heading に手動で ID を与えることもできないし。クロスリファレンスさせる気ないフォーマットをよくも皆 wiki とかナレッジ集積に使いたがるよなぁ

あれはマジで CommonMark に最優先で入れることを検討すべき機能だと思う

まあどうせオレオレ拡張を突っ込むことになるのなら、最初からオレオレスキーマでやっておいて、より弱いスキーマへの自動変換を実装しておくという方向のほうが生産的

昔はそのパーサすらぶっ壊れてたりした (マジで) んだよなぁ……今どうなってるかわからんが

まあ markdown 文法についてはどうせ各種処理系なんだかんだで準拠できてなかったりするし、事実上拡張必須な md で拡張の余地のない文法がフォーマルに定義されていても全然嬉しくないかなぁという気持ちが強いですね

AsciiDoc は拡張に使える汎用構文がちゃんと残っているのでその点ではかなりマシ。というかその点だけで markdown より ✨未来がある✨ と評しても良いだろうと思えるくらいそこは大事

まあ実用面だけで話しても AsciiDoc は処理系に使える言語の縛りがキツいのがなかなか険しいので、そこが改善されないうちは普及も微妙だろうとは思う

adoc、 man page のソース形式としてはちょくちょく使われているのを見る

ｺﾛ試合すっか