良いツールは見えない
(gingerbill.org)- 良いツールとは、ユーザーが作業に没頭しているあいだ背景へ消えていくツールであり、ツール制作者の目標もツールそのものを意識させないことにある
- ツールの欠点を「面白いパズル」として包み直すと、賢そうに見える感覚を実際の生産性と取り違えやすい
vim、emacs、Sublimeのようなエディタ選びは個人のワークフローに合っていてよいが、欠点までアイデンティティのシグナルのように擁護すると、長所と短所を率直に見にくくなる- TUI と GUI の論争でも、現在の実装の不十分さをカテゴリ自体の本質的な限界と見なすべきではなく、多くの問題は良い実装が存在しないために生じている
- 良いデフォルトはユーザーの時間を節約する設計であり、高い設定自由度や急な学習曲線は、それが実際の生産性で報われるときにだけ受け入れる価値がある
良いツールの基準
- 良いツールは見えなくなるべき
- ユーザーがツール自体を意識せずに作業を続けられるとき、ツールは背景へ消えていく
- 特定の作業でツールが足を引っ張った瞬間、ユーザーは再びツールを意識するようになる
- 不足している点を「面白いパズル」として再包装する態度は、ツール評価を曇らせる
- 回避策を見つける楽しさは、ツールの品質を証明しない
- 欠点を趣味のように楽しむことと、ツールが実際に良いことは別問題である
テキストエディタ論争
vimは単なる例にすぎず、同じ論理はemacsやSublimeのような他のエディタにも当てはまる- 一部のユーザーは、
vimの長所よりも欠点を解決する過程を面白いパズルのように称賛する- 一度きりのテキストリファクタリングのためにマクロを作るのが楽しかった、という例がある
- 同じ作業を
Sublimeのマルチカーソルで1分以内に処理したり、簡単なスクリプトで解決できたなら、マクロ作業は実際の生産性という基準では弱くなる
- エディタはワークフローにとって重要だが、特定のエディタを「ハッカーっぽい雰囲気」のためにほとんど宗教のように信奉する態度は危険である
vimやemacsに新しく触れる人にとって、こうした雰囲気が魅力として働くことがある- 慣れは欠点を覆い隠し、その欠点をゲームのように誇らせてしまうことがある
Sublime を使う理由と認めている限界
Sublimeは15年間使ってきたエディタであり、選んでいる理由はいくつかに整理できる- ショートカットがグラフィカルな OS 環境の上位集合に近く、アプリ間を行き来するときの認知的な切り替えコストが小さい
- マルチカーソルは、99.999% のケースでマクロより優れていると考えている
- マルチカーソルは直接的な視覚フィードバックを提供する
- テキスト編集ワークフローにおいて解くべき「パズル」が最も少ない
Sublimeにも欠点は残っている- 必要なツールがなく、プラグインを使ったり別プログラムでテキスト変換を処理しなければならないことがある
- そうした欠点を「面白いパズル」として包み直さず、単に不便さとして受け止めている
vimは基本的な編集ではより良いかもしれないが、grep系の作業ではない大量処理では弱いと見ているvimmotion がSublimeのワークフローよりはるかに生産的だとは感じていない- ターミナルでコードをほとんど書かないため、ターミナル志向のエディタは実質的に必要ない
ツールがアイデンティティになるとき
- ツール選択は、自分がどんな人間かを示す旗のように機能しうる
- 「ハッカーっぽい雰囲気」は単なる美学を超えて、部族的シグナルになることもある
- アイデンティティがツールに結びつくと、欠点を認めることが自分自身を否定するように感じられる
- そのため、欠点に耐えるだけでなく、それを擁護し誇るようになる
- ツールが性格の一部になっている人とは、ツールについて率直な対話をするのが難しい
生産的な感覚と実際の生産性
- エディタのマクロの事例は、生産的な感覚と実際の生産性の違いを示している
- 手ごわい問題を解いたときに生じる賢さの感覚は、実際の成果と混同されやすい
- 難しい仕事を英雄的に感じさせ、賢さを達成のように感じさせるツールは強力に見えるかもしれない
- 同時に、実際の作業速度は静かに遅いこともある
- 率直な基準は没入感や賢さではなく、かかった時間とミスの数である
- 多くの人が布教するように薦めるツールは、この基準では劣ることがある
- 生産性が目標なら、自分の信念を実際に疑い、何がより生産的かを確かめるべきである
TUI と GUI の論争
- 一日中ターミナルにいるユーザーにとっては、ターミナルアプリの利点は明確である
- しかし、ほとんどのプログラマーが一日中ターミナルに閉じこもっているわけではない
- GUI アプリをキーボードだけで操作できないという批判は、GUI が本質的に悪いという意味ではない
- 多くの GUI がキーボード操作を十分にサポートしていないだけである
- GUI をキーボードで操作可能にすることに、本質的に不可能な点はない
- 多くのツール制作者がそれを実装していないか、マウスを頻繁に使うよりキーボード操作のほうが生産的な場合が多いことに気づいていない
- ある特定の TUI アプリが、ある特定の GUI 代替より優れているという比較は妥当でありうる
- しかし、TUI が GUI より本質的に優れているという判断は、現在の実装上の限界を本質的限界と取り違える誤りに近い
Linux デスクトップと設定の楽しさ
- 2026年になっても「Linux デスクトップの年」は来ていない
- 理由の1つは、Linux ユーザーの多くが設定ファイルをいじってシステムを変える作業を面白いパズルとして好んでいる点にある
- 自分でもそうした段階を経験したとしても、時間がたてば、ただちゃんと動くツールを求めるようになる
- 何時間も、あるいは何日も設定することは、もはや望むことではない
- デフォルトは良くあるべきで、すぐに動かなければならない
- 小さな調整が必要なときは、数秒で終わるべきである
- 最大限の設定可能性はツールの目標ではなく、実際に必要なときに使う選択肢であるべきだ
- 人間工学にかなったツール設計とは、良いデフォルトと、必要な場合の逃げ道をあわせて提供することである
良いデフォルトとツール制作者の責任
- 良いデフォルトはツール制作者の責任である
- ツール制作者は、設定・調整・学習の負担をユーザーに押しつけがちである
- 多くの負担は、設計者が判断を避けた結果である
- 「高い設定可能性」は、何の見解も示さないまま問題をユーザーに投げ返す言い訳になりうる
- 良いデフォルトは、ユーザーの時間への敬意である
- ツール制作者が一度考え抜けば、無数のユーザーが同じ悩みを繰り返さずに済む
- 逃げ道は、特殊な要求を持つ本当に少数の人のための仕組みである
- 一般的なケースをきちんと作ることの代わりにしてはならない
急な学習曲線は機能ではない
- あるツールの難しさこそが本質だという擁護もある
- それは、コミットしていない人をふるい落とし、山場を越えれば一生報われるという論理である
- 学習曲線はコストであって美徳ではない
- そのコストに価値があることはありうるが、報酬は実際の生産性でなければならない
- コストを支払ったという満足感自体が報酬になってはならない
- 「何か月も学んだのだから価値があるはずで、他人も従うべきだ」という論理は、埋没費用を能力のように包み直している
- このときパズルは、ツールを使った作業ではなくツールそのものになる
ツール選びより重要な態度
- これは特定のツールに反対する議論ではなく、ツールへの向き合い方に対する批判である
vim、emacs、Sublimeのどれを使ってもよい- 基準は、そのツールが背景へ消え、ユーザーが作業を続けられるようにしてくれるかどうかである
- この基準は個人的な基準である
- 問題は、ツール選択の周囲に付随する物語である
- 限界を機能として包み直す
- 欠点を回避する努力を報酬のように売り込む
- ツールが「使うもの」から「自分の一部」へと昇格する
- ツールがきちんと奉仕していることの最も明確なサインは、ユーザーがそのツールに気づかなくなる状態である
- 最高のツールとは、最も良い物語を持つツールではなく、ユーザーが自分が使っていることを忘れさせてくれるツールである
1件のコメント
Hacker Newsの意見
開発者チーム向けの内部ツールをかなり多く設計してきたので、本当に同意する
以前は、ユーザーが開発者なのだから「内部構造」を開いておくほうがよいと思っていたが、実際にはチームメンバーが本来の仕事をするうえで障害を増やすだけだった
チームメンバーは会社が必要とする仕事をするために私の作ったツールを使うのであって、他では使い道もない小さなツールをいじくり回したいわけでも、そうすべき理由があるわけでもない
今でも抜け道は多く残しているが、ユーザーが自然に成功の落とし穴に落ちるように内部ツールを設計しようとしている
そしてエラーメッセージ、エラーメッセージ、エラーメッセージと、よくあるエラーに対する自動提案が重要だ
記事の例だけにとらわれて、趣旨を見ない人が多いのは残念でもある
ユーザーが重要だと考える仕事を直接こなせるよう助けるなら、設定可能性は非常に価値があるが、それほど重要でない問題を片づけるツールなら、むしろ邪魔になりうる
たとえば Gusto が給与、税金、書類提出を代行してくれるやり方は本当に良い。ほとんど考えたり触ったりする必要がないからだ
しかし、給与・会計・税務が本業だったり、大企業の HR・法務・財務部門で働く人にとっては、そうした単純化は有害になりうる。ツールと格闘することになるか、控えめに言っても、自分の仕事を過度に単純化してしまうからだ
また、実際にお金を払うのが誰なのか、そのツールが監査可能性・セキュリティ・望ましくない行動の制限といった防御的な目的のためのものなのか、それとも創造的な目的なのかも大きな問題だ。創造的な機能のほうが魅力的ではあるが定量化しにくく、最終ユーザーは自分の役割にどれだけ役立とうと、それに見合う大金を払おうとはしない
妥当なデフォルトを用意し、必要ならカスタマイズできるようにするやり方だ。80% のケースから始めて、望むなら変えられるようにし、しかもそれは任意であるべきだ
とくに開発者ツールでは、強い意見を持たせることをためらう傾向がある。ある選択肢が「常に正しい」と確信できないなら、ユーザーに尋ねるほうが安全に見えるし、開発者はかなり細かくこだわるからだ
「95% はたぶんこの方法を望むだろうが、5% にももっともな事情があるので、全員に平等にしておこう」となると、大多数のユーザーにとってより悪いツールになる
カスタマイズを支える仕事は、思っているよりはるかに複雑だ。バグの問題だけでなく、選択肢ひとつひとつがユーザー体験の磨き込みを難しくする。テスト範囲も広がり、より柔軟な抽象化は設計するのもさらに難しい
ただし、なおバランスを取るべき点があって、人々に正しいやり方を強制することだ
きちんとやることで詰まって不満を言う人はいつもいて、多くの場合それを時間の無駄だと感じる
組織の観点での目標は、従業員が在籍しているあいだに最も高い成果曲線を作ることであり、従業員の観点では、キャリア全体での成果曲線を作ることだ
多くの部分は、関係者どうしの関係性に左右される。引っ越し作業員が前日に運動して筋肉痛なら、私の立場では遅くなって悪い結果だが、引っ越し会社の立場では、長期的にはより強くなって多くの仕事をこなせるので良いかもしれない。ただし、その日に辞めるか解雇されるなら再び悪い結果になる
本当の評価対象は、マクロと Sublime での編集のどちらがよいかではなく、マクロを作る思考過程が他の仕事にも役立つのか、そしてその前に何をしていたのかだ
私の経験では、マクロを使ったり Vim を学んだりするのに使っていた時間を、本当に意味のある仕事に使う人はほとんどいない。たいていは退屈していたり燃え尽きていたりして、その瞬間に楽しく感じられる別のことを考えたくてそうしている
問題は、従業員がランダムなスクリプトを書くことではなく、現在の作業に対する切迫感や関心がないことにある
インターフェースが「見えなくなる」効果は、実際にはそのインターフェースの中で過ごした時間の関数だ
書き手が反応している対象は、デザイナーやプロダクト担当者が機能や複雑さを加える裁量的な摩擦に近いように見える
しかし、特定の作業を達成するには、そうした摩擦が必要なこともある。マージコンフリクトを解消する場面を考えればよい。しかも十分長く使えば、そうした「邪魔な」段階ですら背景へと消えていく
具体的には、737 のコックピットは操作装置が非常に密集している。機体自体にも複数のモードがあり、意図された摩擦も多い
それでも 737 を 10 年以上扱ってきたパイロットに聞けば、そのインターフェースは見えなくなったと言うだろう
よく「ひどい」と見なされる Bloomberg Terminal も同じだ。医療分野でも、1 日 8 時間以上 MR スキャン用ソフトウェアを使い、すべての制御に即座にアクセスしたい人にとっては、ボタンだらけのインターフェースがまさに正しい解なのかもしれない
プログラマーは、自分の経験や好みをあまりに早く一般化して、他人に当てはめようとする傾向がある
出典: IDEO で消費者向け・専門家向けソフトウェアを 10 年設計していた
記事はユーザー側からこれを扱っており、中核機能より最終的な価値が低い「追加」機能を学ぶのを楽しむタイプのユーザーがいると見ている
「人々が vim や emacs などを本当に良くて生産的だと感じて使っているなら、私は批判しない。人は慣れ親しんだものに最も心地よさを感じる。しかし私が言っているのは、その慣れのせいでツールの欠点が見えなくなり、その欠点をゲームのように誇示して称賛してしまう人たちのことだ」という部分が核心だ
長年ターミナルを使ってきた立場からすると、人々が理解しないこと自体はあまり驚きではない。会話はたいていこんなふうに流れる
「ターミナルでは簡単なコマンドであれこれできる」
「うちの FrobnicatorStudio にはそのための Ctrl+Alt+So ショートカットがある」
こんな調子で延々と続き、「Vim では4回押せば24行を削除できる」とか「Sublime にはマルチカーソルがある」といった、ほとんど無意味な比較に流れていく
おそらく本当の論点は、ターミナルが小さなコマンドラインツールをパイプラインで組み合わせるやり方によって無限に近いユースケースをカバーできる一方、使いこなせるようになるまで1年ほどかかる学習曲線があるということだ
そこに到達すれば平均的な GUI ユーザーよりはるかに生産的になれるかもしれないが、そこまで行くには献身と苦痛が必要で、多くの人は自分の意思ではなく必要に迫られてそうしている
私の場合、最初の仕事で ssh を使って顧客サーバーを管理する必要があり、そのサーバーには最小限のものしか入っていなかった。しばしば vim ですらなく vi しかなく、その環境で効率よく働く方法を見つける以外に選択肢はなかった
その経験がなければ、ターミナルで仕事を始める苦痛を受け入れていたかは分からない
でもある時点で、そこで時間を無駄にしすぎていると感じた。tshark と jq、昔ながらの bash/awk/grep と gnuplot に戻って再びコマンドラインへ戻り、その後は Python を使うようになったが、それでも tshark の出力は使い続けた
結局、pcap と pcapng のパーサー、ethernet-ip-udp/tcp の処理、さらには完全な Java IDE まで作ることになり、もう戻らなかった
繰り返し使う必要があるあらゆるデータキャプチャ・探索ツールでも同じような曲がりくねった道をたどってきた
こうしたツール改善の反復段階を経験するのは自分だけではない気がするし、これをうまく表す名前付きの尺度があればいいと思う
ターミナルは無限に多くの能力を与えてくれるが、実際に定期的にやることは20個程度である可能性が高い。その20個がすべてなら、学習曲線のせいで説得は難しい
たとえばターミナルにいてビルドスクリプトを探したいなら、
cat packages.json | jq .scriptsのようなことができるターミナルの中では便利だが、VSCode にいるなら
ctrl-p -> packages.json -> ctrl-f -> scrで終わり、実際のキー入力も少ない作業フローは本当に個人的なものなので誰かに変えろとは言わないが、私の場合はプロジェクトをただのテキストとして扱うツールよりも、プロジェクト構造を理解するツールを好むので IDE のほうが合っている
コマンドラインアプリとは、grep、sort、cp、git、ls、tar のようにシェルにコマンドを書いて対話するツールを指す。一般的な使い方を知っていればスクリプトでも使えるので、パイプラインで組み合わせられる
テキストユーザーインターフェースアプリとは、Vim、Emacs、Tmux、Lynx、Tig、Midnight Commander、Claude Code のように、使っている間ターミナルを占有する対話型アプリを指す
こうしたものはパイプラインで組み合わせない。より正確には、普段の使い方のままではパイプラインに入れて使わない。もし可能だとすれば、そのアプリが TUI とは別にコマンドラインインターフェースを提供しているからである可能性が高い
あらゆる問題を解くときに同じツールボックスを使えるようになるまでには時間がかかるが、最終的にはそのほうが効率的だ
ただし説得は難しい。コマンドラインツールでなければ解きにくい問題を実際に解いてみるまでは、その単純さを理解するのは簡単ではない
それでもあらゆる場面でコマンドラインはよく使う。たいてい konsole のウィンドウを開いておき、ビルドやテストが必要になれば Sublime の "build system" サポートの代わりに alt+tab で切り替える
Vim を使うのは ssh が必要なときか、携帯電話で Termux を使うときだけだ
Sublime や VSCode のような拡張可能な GUI ツールも無限に近いユースケースをカバーでき、むしろより安定して再現性のある実行環境を提供する
こうした論争が終わらない理由は、人々が概して閉鎖的な考え方をするからだと思う。他人の立場に立つのは難しく、自分が間違っている可能性を真剣に受け入れるのはさらに難しい
結局この問題が重要なのは初心者にとってだけだ。十分に慣れてしまえば、何を使おうと生産性のボトルネックは道具ではなくなる。もちろん ed なら例外かもしれない
「キーボード操作によるナビゲーションが、しょっちゅうマウスを握るよりはるかに生産的だと分かっていない」という主張については、自分のほうが生産的だと言う人のかなりの部分は、実際には測定したことがない
長年にわたってキーボード対マウスのナビゲーション競争は数多く行われてきたが、テスト設計の細部によってどちらかが勝ったり負けたりし、差がかなり大きい場合も多かった
実際の結果を見る前には、ユーザーがより生産的だと主張していたやり方が負けるケースも少なくなかった
絶対的な生産性指標を追いかけたいのではなく、フローを壊さない環境が欲しいのだ
多くの人にとって、マウスを握る行為はフローを壊し、不自然に感じられ、1秒遅いことより悪い場合すらある。頭の中にあった文脈から外れてしまうからだ
私の場合、仕事中にマウスを使うのは自然なことなので、あらゆるナビゲーションをキーボードで行うように作業フローを変えるのは、ある状況でほんの少し時間を節約できるかもしれないという理由だけで非常に大きな追加労力を払うことになる
ワープロ、IDE、ファイルマネージャーのように、読んで、入力して、読み書きしたものを処理することが中心のツールでは、ユーザーがショートカットを習得したとき、キーボードナビゲーションのほうが速く自然であることを示せる
逆に、テキストではない視覚情報が中心のツールでは、キーボード対マウスの議論ははるかにマウス寄りになる
それでも、効果的なショートカットがメニューやアイコンよりはるかに有用になる瞬間はある。CAD や 3D モデリングソフトウェアを見れば、ユーザーの作業の 90% は視覚的に表示された空間データを扱うことだが、ツール切り替えやツール設定変更のショートカットを知っていればずっと速くなり、入れ子のメニューをいちいち漁る必要も減る
筆者が自分の道具に慣れているという事実を、それがより優れている証拠と取り違えているように見えるのが気がかりだ。
現実にはどんな道具にもトレードオフがあり、ユーザーが道具Xを道具Yより好むのは、愚かだからではなく、その道具の熟練者にしか分からない affordance をよりうまく活用しているからである可能性が高い。
開発者に vim、emacs、Sublime Text をそれぞれ10年ずつ使わせたとしても、どれがより良いか確信は持てないだろう。個人的な好みはあるにせよ、なぜ他の人が別の道具を好むのかも説明できるはずだ。
慣れていないソフトウェアにまともな機会を与えたことがないところから生まれた議論に見える。
長くやってきた古参の印とは、あらゆるソフトウェアと、それを改善するという約束に対するぼんやりとした不信感だと思う。長期的には、すべてのソフトウェアは平凡さへと収束する。
道具の摩擦を機能だとみなす考えに同意しないと言っただけだ。
彼の論旨をそのまま使って、Vim が自分にとって完璧なエディタであることを示すこともできる。Vim を使っているとき、それは自分に見えなくなるからであり、ある程度は Vim を自分の望む道具に作り替えたからでもある。
彼は Sublime を自分の望む道具に作り替えた。それでも基本的な要点は変わらない。誰か他の人が使うものを作るなら、その道具をユーザーにとって見えなくすることは強力な特性だ。
平凡であるとは、「並み、または一般的な品質」を意味する。
次の CRUD アプリを作るとき、最新かつ最高の並外れた技術が必ずしも必要とは限らない。
私が書いた文を引用するとこうだ。「私を当惑させるのは、多くの人がその摩擦、つまり道具の限界を迂回しようとする努力を『面白い』部分として扱い、それをその道具が素晴らしい証拠であるかのように宣伝することだ。」
これは、私や他の誰かがなぜある道具を選ぶのかとは無関係で、欠陥をパズルゲームのように回避すべき対象として扱う態度についての話だ。
良い道具のメンテナーは、ユーザーが実際にその道具をどう見ているかより、はるかに否定的に受け取りがちなことが多い。
「今日は10人がバグや不足している機能に不満を言い、9990人は問題なく使った」と「今日は10人が不満を言い、90人しか問題なく使えなかった」を区別するのは難しい。だが、ユーザー満足度を90%から99.9%に引き上げるのに必要な努力は桁違いだ。
これは多くのオープンソース・メンテナーの燃え尽きの大きな要因だと強く疑っている。
不満を持つユーザーは満足しているユーザーよりはるかに目立ち、新規ユーザーが増える速度に比べると、同じ量のバグ報告や機能要望を生み出す不満ユーザーの割合は低下していく。
その結果、メンテナーには、どれだけ改善しても全体の品質に対する手応えが変わらないという錯覚が生まれ、続ける動機が削られていく。
この問題への良い解決策はよく分からない。明白な答えは、うまく動いているときにもっと頻繁に称賛することだが、現実にはなかなか起きない集団行動の問題に近い。
個人的には、何かがうまく動いたら意識して頻繁に、熱意をもってポジティブなフィードバックを返すようにしているが、皆がそうしない限り大きな違いを生むのは難しい。
この引用を思い出す。
「私たちは、いつも腰をかがめてせわしなく卑屈に振る舞う人を見れば、おそらく『なんて謙虚なのだろう！』と言うだろう。しかし、本当に謙虚な人は目立たない。世はその人を知らない。」
~ Tito Colliander
「道具があなたによく仕えている最も明白な兆候は、それを意識しなくなること、つまり見えなくなることだ。欠陥を趣味に変えないので、欠陥を称賛せず、少し苛立ちながら迂回するだけだ」という部分は、道具よりもユーザー依存性が大きいように見える。
もちろん、異なる道具は異なるユーザーを引き寄せるだろうし、強い相関関係を測定することもできるだろう。
また、この立場はバランスを欠いている。道具は決して完璧ではなく、ときには改善できることに気づき、その変更を実装することと、それが習慣に与える影響を天秤にかけなければならない。
長く使うほどそうした変化は小さくなるだろうが、使い方は生涯を通じて進化するものであり、道具もそれに合わせて変わるのが自然だ。
かなり独特な解釈だと思う。
筆者が Vim は「見える」と執着しながら、Sublime のマルチカーソルや機能はそうではないと示唆しているのが奇妙だ。頭がもう考えないように訓練されたからといって、見えにくくなるわけではない。
マルチカーソルは多くのツールで基本機能ではなく、効果的に使うことまで含めれば学ぶべき対象だ。Vim のキーバインドと同じである。
しかも Vim はターミナル専用ユーザー向けの TUI の選択肢以上のものだ。キーボードを自分の身体の自然な延長として身につけた人たちが、マウスとの行き来を続けずに済むよう使うキーバインドでもある。Sublime を15年使っているユーザーにとってマルチカーソルがそういう存在になりうるのと同じように。
「一回限りのテキストリファクタリング問題を処理するためにマクロを作ることがどれほど『楽しい』かを語る人たちを見たことがある。だが、彼らが何をしていてどれだけ時間がかかっているかを見たとき、正直な反応はこうだった。Sublime のマルチカーソルなら1分でやるか、あるいは短いスクリプトを書いただろう。」
そして「私を当惑させるのは、多くの人がその摩擦、つまりツールの限界を回避しようとする努力を『楽しい』部分として扱い、それをツールが素晴らしい証拠であるかのように宣伝している点だ。」
Vim マクロを効果的に使えるならそれは良いことだ。だが、数十年 Vim を使っていても使えないのなら、それを『楽しい』部分として宣伝するべきではない。
最もよくある感情は、学習曲線はあるが最終的にはそれだけの価値がある、というものだ。
何を意味しているのかわからない。Vim マクロも作成中は直接的な視覚フィードバックを与える。録画しながら普段どおりに編集し、あとでその編集を再生する方式だからだ。
作成中にテキストへのリアルタイムの効果を見ずにマクロを使うことが技術的に可能かどうかはわからないが、私はそうしたことはない。
気になってマルチカーソルを調べてみたが、利点は説明しやすい単一のインターフェースにあるようだ。実際には、これを置き換えるために複数の Vim コマンドを使うことになるだろう。
マルチカーソルを使う価値があるたいていの作業では、マルチカーソルがマクロより優れているかもしれないという点には同意する。だが、普通そういう作業にはマクロを使わない。
私がマクロでやっている作業の大半は、マルチカーソルではできないように思える。
「この状況ではマルチカーソルが素晴らしく、Vim には良い代替がない」という例があるなら、間違っていると証明してほしい。
だからといってマルチカーソルに学習曲線がないという意味ではない。依然としてカーソルを正しい位置に置く方法を考えなければならない。
「見えない」という表現は、以前 emacs magit を説明するときに使ったことがある。
git の出力の上にある薄いレイヤーのようなもので、現れて UI の状態からパラメータを推論し、いつもの git コマンドを呼び出してから消える。
軽くて速い。大きなプロジェクトではそうではない気もするが、そうらしい。