Development

いろんなワードで pacman -Ss してみて眺めていたら，termtosvg というやつを 見つけたので試してみた。 結論：すごい。ただ alternative screen buffer ができないみたい。 ソース見たら CSS で表示位置をずらしてアニメーションしているように見せているっぽい？ よくわからぬ。

Minecraft で読み込まれるチャンクの半径は 3–16 の間で選べるのだそうだ。 ということは，5 チャンク飛ばして更新されているか確認していけば 3 チャンクだったとしても どこかのチャンクにはぶつかるということだ。 というわけで，1 チャンク見て，間の 5 チャンクは更新されているかの確認もせずに 飛ばして，更新されていたら間のチャンクがアップデートされているか確認する ということにすると，何も更新がない場合の生成がかなり速くなった。 やっぱりやることを減らすと簡単にかなり速くなる。

端末エミュレータで URL に飛ぶといえば，たいていのものについている URL の自動検出機能 を使うというのがまあ普通の答えになる気がするんですが，任意のテキストに URL を割り当てる エスケープシーケンスというのが世の中には存在するという話。（今日知った） TL;DR ハイパーリンクは次のようなエスケープシーケンスで実現できる。1 "\e]8;;${URL}\a${LABEL}\e]8;;\a" 例えば，http://example.com に飛ぶ 「Click here」というリンクを作りたかったら， 下のようにする。 "\e]8;;http://example.com/\aClick here\e]8;;\a" 経緯 これを知ったきっかけというのは， $ coredumpctl --help というコマンドを実行したことだった。ヘルプの下の方に coredumpctl(1) man page という点線のついた文字が表示されていて，右クリックのメニューからリンクをたどってみると， マニュアルページのウィンドウが表示されて驚いた。僕は plain-old な man コマンドでの 表示の方が好きなので，HTML 変換されたものが表示されたのには納得がいかなかったが。 まあそんなことはさておき……。

前のポストでテキストエディタ自作の知見のことを思い出したので，書いておこうかなと。 この記事では，端末で動く簡単なテキストエディタを作ります（ただし， そんなにまとまっていないかつサンプルコードとかも限りなく少なくなると思うので， 断片的な情報にすぎない気がする）。 この記事では GNU/Linux のシステムを前提としますが，macOS や BSD 系の OS など Unix 系の OS であればほとんどの内容は通用すると思われます。 また，Windows Subsystem for Linux (WSL) でもおそらく動作しますが， テストはしていません。 また，端末エミュレータは xterm 互換である必要があります。 GNOME 端末，Konsole，mlterm など主要な端末エミュレータ（端末）であれば問題ありません。 WSL を使っている場合で，Windows Terminal を使っている場合， 細かい部分で非互換が発生することがあります。 なお，筆者は ArchLinux 上の GNOME 端末で開発を行いました。

今日は小さいツールを2つほど作って，ちょうど700行コードを書いた。 まあ空行とかコメント（ほとんどない気がする）も含まれるのであまり意味のある数字ではないけど。 1つはパイプラインの中で標準入力をテキストエディタで編集して標準出力に流すというもので， なんかこんなのすでにシステムにインストールされたりしてそう……。 作っている時はパイプラインの中で使うという発想があまりなかったし， あまり機会がある気がしないが，ヒアドキュメントとかヒアストリングとかを意識して hereed というゴミみたいな名前にした。 もう1つは Wake-on-LAN のユーティリティで，0個以上の予め登録したホストを 同時に Wake-on-LAN できるというものだ。 送るホストを選ぶところは，以前にテキストエディタを作った時の 端末の制御の知見があったので，それが使えた。non-canonical mode にするとか， エコーバックを無効にするとか。 まあ知ってれば何も難しいことはないけれど。 設定ファイルが json なのが Unix のツールとしてイケてないと思うけど， 設定の構造的に json が都合が良かったのでまあ使った。

久しぶりに触った。例によってマップの実装に使った訳だが。 プラウザの履歴をゴニョゴニョできる API だが，適当に使うのは割と簡単。 history.pushState(null, null, '?foo=bar'); みたいな感じで URL のクエリを書き換えたりとかできる。 MDN を見たら第一引数と第二引数にいろいろ渡していたが，めんどくさいので null でよさそう。 書き換えを listen する方は， window.addEventListener('popstate', () => { // なんか処理 }); とかでよさそう。これが呼ばれたときには URL が書き換わっているので， それを location.href とかで取ればよさそうな気がする。 真面目にやるなら push したときの値を受け取って使う感じになるんだろうけど。 onload と同時に popstate が起こるブラウザもあるらしい。怖いよ〜。 参考 https://developer.mozilla.org/ja/docs/Web/API/History_API https://qiita.com/nenokido2000/items/2dd8da77d06837c8a510

ブロックの高さと名前が出せるようになった。 パーサーをサーバーとして実行てきるようにして，PHP で Unix ドメインソケットで話させる みたいな感じにした。 サーバーの実装だけど，最初 wait してなかったせいで，大量のゾンビプロセスを作ってしまった。 これは，犠牲となる子プロセスを作ったあと，そのプロセス内でプロセスを立ち上げて レスポンスを返す感じにして，即座に終了する最初の子プロセスをwaitするようにして解決した。

これは GNOME に限らず，XDG 準拠のデスクトップ環境ならどこでも使える気がするんですが。 基本的にデスクトップエントリーのファイルは /usr/share/applications か /usr/local/share/applications に作ればいいと思うんですが，権限がないときとか， システムワイドにインストールしたくない場合とかがある。そのときは ~/.local/share/applications に置けばいい。~/.local は /usr/local に対応していると考えていいっぽいです。 あと，アイコン。デスクトップエントリーのファイルでは，Icon というキーでエントリー用のアイコンを 指定できるんですが，これは，テーマごとのアイコンのディレクトリから探索されます。 で，システムにインストールする場合は， /usr/share/icons か /usr/local/share/icons に 置けばよくて，ユーザーの場合は ~/.local/share/icons に置けばいい。 icons 以下にテーマのディレクトリがあるんですが，だいたいのテーマは hicolor を継承しているので， /usr/share/icons/hicolor に置けばいいみたいです。 そしてこれはちょっとハマったんですが，48x48 のアイコンは必ず準備しないと，他の解像度のを用意しても アイコンが認識されないみたいです。あと，画像のファイルは icons/テーマ/解像度（e.g. 48x48）/apps に置く。解像度のディレクトリに直接置いても認識されないです。

今更ながら，技術評論社の Software Design を買い始めてみた。 前々から気になってはいたのだが，こういうのは一回買ったら毎回買わないといけなくなるので 今まで買わないでいた。 あと，今まで調べてなかったけど，年間購読にするとちょっとだけ安くなるみたいなのも あるっぽい。

一月は行く，二月は逃げる，三月は去るみたいな，この時期にありがちな，でもちょっと早いような話をしつつ……。 でももう二月なんで早いですよね。まあそんなことはどうでもいい。 こないだ作った Minecraft のマップ画像を生成するやつを C++ で書き直し始めてみたりした。 でもまあ今日はそんなに作業できなかったのでほとんどヘッダファイル書いたら終わったみたいな感じだけど。 もともと Python で書いていたやつは anvil-parser というライブラリを使っていて， そのライブラリは NBT なる Minecraft の独自バイナリ形式のパーズには nbt という別のライブラリに 任せているっぽかった。nbt というライブラリのリポジトリを見に行ってみたら，チャンク読むところとかも実装されていて， なんかマップを生成する example も存在したんですね。うーん。まあいいやろ。 で，anvil-parser ってのはそのライブラリのチャンクの実装とかは使ってなくて， その部分は独自でやってるみたいでした。まあ古い形式にしか対応してなさそうだったのでそのせいかな， という感じがします。