Vimにコントリビューションした過程のログ
vim-jpで長文書けないんだけどとぼやいていたら
ちゃんとしたもの書かないと、って思わせるのが本当によくない
との返事を頂いたので、あえてScrapbox上で箇条書きでやっていきます
やったこと考えたこと書いたら結局長文になってしまった…
Vimのsha256()関数がblobを受け取らないことに気が付いたのでパッチを書いていた テストを書く段階でvim-jpに進捗を投げていたらlist2blob()との組み合わせでエンバグしていたらいけないので使ってみたらどうだろうかと勧められた
実際に使った所別の問題が本当に出た
range()関数と組み合わせると謎のエラーが出るというもの
E685: Internal error: tv_get_number(UNKNOWN)と出るので本当に内部エラーっぽい
せっかくC多少は書けてVimのパッチも書いたことがあるし、何より修正しないと自分が困るので自分でやることにした
Vimは現在GitHub上で作られたPRも見てくれるのでPRを作成するのが一番楽である 何はともあれVimのビルドが済んでいるのが楽なのでリポジトリトップで./configure && make -j8を打ちこんだ
凄い人はこれと同時並行でもう修正を始めるらしく凄いですね、私は凄くないのでvim-jpを見ながらだらだら過ごしていました。 終わったら/src以下でctags -Rも走らせておく
これをやるとVim内で<C-]>や:tag等によるタグジャンプができるようになる
問題が起きているのはVim scriptの関数で、Vimの内部ではVim script関数はf_{関数名}で表現されているため:tag f_list2blobで件の関数の中に飛ぶ
内部関数名の表現は事前に読んで知っていたが、一般に似た要素は似た箇所にまとめられているので知らない物を探す時は意識しておくと便利
タブを切って:tag f_rangeも開く
中身を読んだ所でrange()で生成されたリストは遅延評価する仕組みになっていたことを思い出す
他の場所で使用する際にはCHECK_LIST_MATERIALIZE()を呼ぶこととコメントに書いてあるのを発見
多分原因これだなと当たりを付けたのでf_list2blobに戻り上記の呼び出しを探した所、確かに書かれていない
リストにアクセスしている部分の前に書いて再びmakeした所問題が直っているのを確認
テストを書く
Vimのテストはsrc/testdirに固まっているので、そのディレクトリ以下でlist2blob()に対するgrepを実行した所test_blob.vimに書かれているらしいので、そこに追記
testdir内のREADME.mdにmake test_<subject>でそれだけ実行できると書いてあるのでその通りに実行
修正してないVimで落ちて修正したVimで落ちないのを確認
コミットしてGitHubにプッシュ
私は過去にコントリビューションした事があるので既にforkリポジトリがあったが、初めての場合はGitHubのUI上もしくはgh経由でforkしておく必要がある
GitHub上でIssue及びPRの作成
Issueテンプレートがあるのでそれに答えるとIssueが生成される
PRはそれにリンクした
PR作るなら別にIssue作らなくてもいいよとのこと
PRにコメントを移した
しばらく待っていたらマージされました
最近はco-authorに名前を載せてくれるようになりました、なんやかんや言って自分の名前とかアイコンがコミットに出るのは嬉しいですね