Vimconf 2024 で発表した理由とその補足情報
始めに
私は Vimconf 2024 に参加し、「The latest dark deno powered plugins」というタイトルで発表を行いました。
それぞれの発表の感想は他の人がいくらでも上げてくれると思います。
私は私にしか書けない記事として、発表の補足情報となぜ今回発表したのかについてここに記録しておこうと思います。
Vimconf 2024 で発表した理由
自分は人前で発表することは嫌いではないのですが、正直にいうとスライド作りが苦手です。
スライドを作るならば聴衆に分かりやすいように見た目に凝ることが多いのではないかと思います。
私もあのようなスライドに憧れはしますが、自分は過剰な装飾が苦手であり、文字情報だけでよいのではないかと思ってしまう性分のようです。
それでも今回発表することにしたのは、コロナ禍もあり私が前回 Vimconf で発表してから随分と年数が経っていたからです。
自分のなかでのプラグインに対する思想も完全に固まっていたので、発表としてまとめる価値はあると思いました。
自分のスライドで語り切れない部分は自分の熱いパッションでなんとかしてみせようと。
今回の Vimconf の発表は審査落ちになった人が数多くいるようです。その人達の代わりに自分が発表の場にいる、それだけは忘れないようにしておきたかったのです。
さらに今回は私の思想「Shougoism」を海外の人にも発信しようという意図もありました。情報発信は SNS 等で時々しているのですが、その情報発信はどうしても vim-jp の中に閉じてしまっていたり日本人向けになりがちです。
Vimconf は国際カンファレンスであり発表資料も英語で作成する必要があります。自分のプラグインとその思想を海外の人にも知ってもらえるチャンスだったのです。
ちなみに今回のスライド作成には typst を利用しました。
typst は TeX ほど複雑ではなく、テキストエディタでスライドを作成することができるのでお勧めです。
暗黒美無王が出てこなかった理由
「暗黒美無王」とは実は私の理想とする想像上の存在なのです。テキストエディタを極めた結果、人間を超越しテキストエディタと一つになった究極の人間が「暗黒美無王」です。
私は私の理想の存在に近づくために暗黒美無王という人物を演じている、本物の暗黒美無王になるためにはテキストエディタとなる必要があるのです。
今回の発表では暗黒美無王については省きました。私の思想を説明する上ではノイズであり不要と判断したためです。
テキストエディタの設定とは何か
テキストエディタの設定とはベースとなるテキストエディタを使って自分のテキストエディタにしていくことを意味します。
自分の考える理想のテキストエディタと一般的なテキストエディタにはどうしてもずれが生じるので、それを合わせていく作業が必要となるのですね。
「自分でテキストエディタを作らないの」とたまに聞かれることがあるのですが、皆さん実はテキストエディタを自作しているのです。
テキストエディタを設定しない人であっても他のツールと併用したりシェルを設定したりは皆やっているのではないでしょうか。
これらも広義の上ではテキストエディタの設定と捉えられます。
vim-fall と ddu.vim の思想の違い
ありすえ氏の発表した「vim-fall」の思想は私から見ても興味深いものでした。
実装に denops.vim を利用しているところや Vim/Neovim への両対応、TypeScript を用いた設定など共通点も数多くあるものの、私の思想とはかなり違っています。
主な違いについて後述します。
vim-fall は Vim script から設定ができない
ddu.vim は TypeScript による設定と Vim script による設定の両方に対応していますが、vim-fall は TypeScript からしか設定ができません。
その代わりに TypeScript オブジェクトを使った高度な設定が可能です。
私自身は ddu.vim が Vim script から使えることの価値も感じているので、そこはトレードオフと言えるでしょう。
vim-fall の拡張機能は Vim プラグインではない
vim-fall の拡張機能は完全に TypeScript オブジェクトであり JSR 等から取得が前提で Vim プラグインではありません。
よって Vim プラグインマネージャーによる管理はできません。
おそらく、ブラウザで JSR のモジュールのページからドキュメントを参照する想定なのでしょう。
vim-fall 本体のドキュメントも vimdoc のほうにはなく、JSDoc や github Wiki に依存しており、あまり Vim プラグインのようではありません。
ddu.vim の場合は拡張機能も完全に Vim プラグインとして扱い、パスを通す必要があります。ドキュメントも完全に vimdoc のほうに書くようにしています。
分かりやすくいえば TypeScript モジュールを Vim プラグインにしたものが vim-fall であり、TypeScript で書かれた Vim プラグインが ddu.vim です。
vim-fall はモードレス = 候補の絞り込みにのみ対応している
vim-fall は他の一般的な fuzzy finder と同様に絞り込み専用でモードレスです。
モードがあると実装が複雑になりますし、そもそもモードに対応している fuzzy finder は少ないので仕方のない割り切りかもしれません。
vim-fall はキー入力を奪う
vim-fall は ctrlp.vim と同様にユーザーのキー入力を奪う方式です。
この仕様は他のプラグインや設定と干渉しにくく、実装しやすく作りが堅牢になりますが、他のプラグインと連携が仕辛いこと、設定の柔軟性が下がるのが欠点です。
ddu.vim はキー入力を奪わないように、自由にユーザーが設定できることを第一に設計しています。そのために実装や設計でとても苦労しても、です。
vim-fall はデフォルト設定が多い、拡張機能を同梱している
vim-fall は他の多くの fuzzy finder と同様に「設定が面倒」な人向けに設計されたようです。デフォルト設定が豊富で、よく使う拡張機能はほとんど同梱されています。
これはプラグインの導入が楽になる利点がありますが、今後本体が肥大化する恐れがあります。何を標準として入れる入れないの選択が必要です。
基本的には作者が使う機能はデフォルトで入るが作者が使わない機能はデフォルトでは入らないというものになるかと思います。
ただ、その場合作者が後から使わなくなってしまった機能は外すのかという問題は発生します。
vim-fall は telescope.nvim と同様に feature-rich でありデフォルトの見た目にはかなりこだわっているようです。
私はデフォルトが豪華で機能をどんどん無効化していくよりも、最初はシンプルで後から必要な UI を一つずつ構築していくほうが好みです。
vim-fall は特定のクラスではなく関数で拡張する
vim-fall は関数を用いてオブジェクトを生成し機能を拡張するようです。ddu.vim はクラスを用いて拡張しています。
関数とクラス、どちらがよいかは難しいところです。
クラスの利点はデフォルトの実装を制御しやすいところにあると思われます。
これがオブジェクトだとデフォルトの実装は呼び出し側で与えなければいけません。
デフォルトの実装を拡張機能から参照するということもやりやすいです。
関数だと生成されたオブジェクトの合成や拡張は容易になると思います。
vim-fall は一つの source(picker) しか同時に扱えない
vim-fall は ctrlp.vim などと同様に一つの source(picker) しか同時に扱えないという割り切りをしています。
この仕様だと実装がしやすくなりますが、複数の source(picker) を同時に扱うことができません。
その代わりに使用する source(picker) を切り替えることが可能です。そこは ctrlp.vim に似ています。
ddu.vim は複数の source が同時に使用可能です。その代わり実装が複雑になります。
vim-fall は floating window(popup window) 専用である
vim-fall は telescope.nvim と同様に floating window(popup window) にのみ対応しています。
そもそも入力を全て奪う方式であるし、fuzzy finder を画面に表示しながら別の作業を行うことは考えていないためそれでよいのでしょう。
ddu.vim(ddu-ui-ff) はもちろん floating window にも対応していますが、画面分割にも対応しています。
もし今後 Vimconf で発表することがあるとしたら
今年の Vimconf の発表で自分自身かなりやりきったと思っています。
もし次の発表機会があるならば LT で ddt.vim について簡単に宣伝したり、自分の Vim 開発スタイルについて喋ることになるでしょうか。
発表ではデモを入れる時間はなかったので懇親会で簡単にデモをしたのですが、自分のスタイルは自作プラグインにかなりの部分が依存しており他の人が見ても興味深いものであるようです。
それでは、また次の Vimconf でお会いしましょう。
Discussion