開発

Vimの冗談命令UserGettingBoredは動作しない

Vim文書に残る冗談命令UserGettingBoredの来歴と、2022年に実現した拡張機能をたどる。

8分で読める SINGULISM 編集チームが確認・編集

Vimの冗談命令UserGettingBoredは動作しない
Photo by Mohammad Rahmani on Unsplash

Vimの自動命令一覧に、実行されない冗談の項目が残されている。名称はUserGettingBoredである。文書上の説明は、利用者が同じ鍵を42回押した際に発生するという内容だ。末尾には笑顔記号が付され、冗談であることが明示されている。

Lobstersのevanhahn.com via raymiiの報道では、この項目が文書と検査符号にのみ存在すると紹介されている。実際に自動命令として登録を試みると、群や事象が存在しないという誤りが返る。動作を伴わないにもかかわらず、VimとNeovim、Vim Classicのいずれにも記述が残る点が注目されている。

自動命令は、特定の事象を契機に命令や関数を実行する仕組みである。緩衝区の生成から書類の保存まで、100を超える事象が定義されている。利用者はTextChanged事象に書き込み命令を結び付け、自動保存のような振る舞いを実現できる。拡張性の中核を担う機能である。

100超の事象に紛れた一つの冗談

自動命令の事象は、編集作業の節目に対応付けられている。緩衝区への出入り、読書と書き込み、焦点の移動など、細かな契機が用意されている。利用者は用途に応じて処理を割り当て、作業の反復を減らすことができる。文書は各事象の発生条件を厳密に定めている。

その中にあって、UserGettingBoredの記述は異質である。原文の文書は次のように記す。

UserGettingBored: When the user presses the same key 42 times. Just kidding! :-)

同じ鍵を42回押すという条件は、他の事象の定義と比べて具体性を欠く。42という数字は、英国のSF小説に由来する文化的な引用として広く知られる。末尾の笑顔記号が、仕様ではなく遊びであることを示している。真面目な参照文書に残る余白として読める。

この項目は実行基盤を持たない。登録を試みた場合、処理系は該当する群や事象がないと応答する。検査符号の中には名称が現れるものの、発火の経路は用意されていない。利用者側から呼び出す手段もない。文書上の存在に限定される。

2000年に遡る記述の変遷の歴史

来歴は2000年7月に遡る。Vimの作者であるBram Moolenaarがこの項目を加えた。当時の説明は、利用者がCTRL-Cを押した際に発生するという内容だった。末尾には冗談である旨が記されていた。当初から動作を伴わなかったとされる。Vim 6.0の公開より1年以上前の出来事である。

2001年8月には、説明文に笑顔記号が追加された。記述は「When the user hits CTRL-C. Just kidding! :-)」となった。機能の変更ではなく、語調の調整である。冗談としての性格がより明確になった。文書の履歴に残る小さな修正である。

2013年には、現在の形に改められた。条件がCTRL-Cから、同じ鍵を42回押すことに変わった。笑顔記号は維持された。以後、VimとNeovimの双方で同趣旨の記述が継承されている。12年を挟んだ言い換えが、現在の知名度につながった。

継承の背景には、文書と検査符号の保守方針があると見られる。実害がない記述は、削除より維持が選ばれやすい。互換性の確認対象から外す手間も避けられる。結果として、20年以上にわたり冗談が残った。開発用具の文書整備を扱ったNext.js Server ActionsとRSCの技術的関係を解説でも、仕様文書の読み解きが重要性を持つことが示されている。

42回連打で俳優画像を表示する拡張

2022年には、この冗談に着想を得た非公式の拡張機能が登場した。作者は開発者のMike Smithである。挿入モードで同じ鍵を42回押すと、俳優Samuel L. Jacksonの画像が表示される。冗談の条件を字義通りに実装した内容である。着想から22年を経て、初めて実行可能な形になった。

実装は利用者側の操作を数える単純な構造である。特定の編集機能を改善するものではない。作業効率に寄与しない点で、実用的な拡張機能とは一線を画す。娯楽としての性格が強い。それでも、文書の記述を実際に動かした事例として注目された。

この拡張機能は、公式の処理系に取り込まれたわけではない。利用には個別の導入が必要である。公式の自動命令一覧に発火の経路が加わった事実もない。冗談の公式化というより、共同体による応答と位置付けられる。周辺の動画再生用具などと同様、個人の工夫が機能を補う構図はLitPlayer、SMB/Jellyfin対応Android動画プレーヤーが示す個別課題の解決とも重なる。

冗談を残す文化と開発現場の余白

Vimの開発史には、実用一辺倒ではない記述が散見される。文書の隅に残る冗談は、保守の緊張を和らげる役割を果たす。初学者が発見した際には、取っ付きやすさにもつながる。堅い参照文書に人間の手触りを残す手法である。

同様の遊びは、他の基盤programにも見られる。復活文字や隠し命令、記念日で変わる表示など、実害のない範囲での仕掛けが継承されてきた。削除されずに残る条件は、保守に支障がないことである。動作に影響せず、検査に混乱を与えなければ維持される。今回の項目もその条件に合致する。

一方で、参照文書の正確性を重視する立場からは、実在しない項目の記載は望ましくないとの見方もある。自動化された文書生成や翻訳の過程で、冗談が仕様として扱われる恐れがある。初学者が誤って信じる可能性も残る。共同体の規模が拡大した現在、冗談の維持には明示的な合図が欠かせない。携帯端末や周辺機器の動向を伝えるOnePlus欧州撤退、Xteink新型とAYANEO新機種のように、事実と観測を分ける姿勢が文書にも求められる。

編集部の見解

短期的には、開発用具の文書に残る遊びへの関心が高まると見る。技術掲示板やSNSでの共有が増え、類似の記述の発掘が進む可能性がある。VimやNeovimの文書を読み込む新規利用者が増えると評価する。拡張機能の自作が促される効果も見込めると評価する。

長期的には、基盤用具に余白を残す設計思想が再評価されると見る。効率の追求だけでは共同体の持続性は保てないとの認識が広がる可能性がある。保守の継承において物語性が求心力になると評価する。堅い仕様と文化的な記憶の両立が課題になると見る。

残る問いは、冗談と仕様の境界をどこに引くべきかという点だ。実在しない機能の記載は初学者に混乱を与えるとの見方もある。自動生成文書が冗談を真に受ける危険も残る。共同体の合意をどう可視化するかが問われていると評価する。

参考

よくある質問

UserGettingBoredとは何か
Vimの自動命令文書に残る冗談の項目である。同じ鍵を42回押すと発生すると記されるが、発火の経路はなく実行されない。文書と検査符号にのみ存在する。
実際に使おうとするとどうなるのか
自動命令として登録すると、群や事象がないという誤りが返る。VimとNeovim、Vim Classicのいずれでも動作しない。2022年の非公式拡張機能でのみ条件が再現された。
なぜ削除されずに残っているのか
動作に影響せず保守の支障にならないためと見られる。2000年の追加後に文言が調整され継承された。共同体の文化的な余白として維持されている。
出典: Lobsters

コメント

← トップへ戻る