Vim の専門家はなぜタブよりもバッファを好むのか? [closed] 質問する

ZyX が #vim で言ったように、この質問は「なぜ Vim の専門家は温かいものよりも美味しいものを好むのか？」のように聞こえます。

「Vim エキスパート」はタブよりもバッファを好みません。彼らはバッファをファイル プロキシとして使用し、タブ ページをワークスペースとして使用します。バッファとタブ ページは目的が異なるため、どちらか一方を他方より優先することはまったく意味がありません。

バッファとタブに関する問題は、独立した事実の組み合わせによって引き起こされる混乱の問題です。

1. ほとんどの「最新」のテキスト エディターと IDE では、読み込まれたファイルを表すためにタブメタファーを使用します。このメタファーは情報システムとして機能し、ユーザーに開かれているファイルとその状態を示します。また、対話型デバイスとして機能し、ユーザーは開かれたファイルを操作 (並べ替え、選択、閉じるなど) できます。多くの制限があるにもかかわらず、タブはどこにでもあり、人々はタブに慣れており、どこにでもあることを期待しています。

2. Vim は、ユーザーがアドホックな「ワークスペース」を作成する方法として、7.0 でタブ ページ:helpを導入しました。タブ ページの機能、特定のオプション、特定のコマンド、またはセクションには、タブ ページをファイル プロキシとして使用できる、または使用すべきであることを示唆するものは何もありません。

   もちろん、「タブ ページ」という名前と外観以外は何もないので、混乱を招きます。

3. はデフォルトで無効になっており、見つけるのも簡単ではありません。がないと:set hidden、Vim では現在のバッファを書き込んだり、その変更を破棄したりせずに別のバッファに切り替えることができなくなります。そのオプションを知らない新しいユーザーは、ウィンドウを頻繁に使用するか、最も近い「タブのような」機能であるタブ ページを使用するしかありません。

「タブ ページ」は、特にドキュメントを読むのは時間の無駄であるという考えが支配的な時代に、その機能に付ける名前としては残念な選択です。

Vim では、タブ ページはウィンドウ上に構築された抽象化であり、それ自体がバッファー上に構築された抽象化です。新しいレベルごとに便利な機能が追加されますが、ワークフローが制限されます。

「バッファ方式」

バッファベースのワークフローでは、作業中のファイルは単一の次元に沿って分散されます。バッファを循環させたり、バッファ名の一部 (補完機能付き) または番号を入力して特定のバッファにアクセスしたり、バッファを切り替えたり、簡単にターゲットを設定したりできます。基本的に摩擦はありません。

1. 8 つのバッファーが開いていますが、表示されるのは 1 つだけです。

   

2. 番号による切り替え:

   

3. 名前による切り替え:

   

バッファは Vim のファイルプロキシです。ファイルの観点から考えると、バッファの観点から考えることになります。

「窓の道」

ウィンドウベースのワークフローでは、バッファのみを使用する場合と同様に、"ファイル" は単一の "仮想" 次元に沿って、また他の 2 つの "物理" 次元に沿って分散されます。ただし、これらの次元が存在する直交座標空間はほぼ完全に分離されています。つまり、別のバッファに移動することは "別のファイルへの移動" を意味しますが、別のウィンドウに移動することは意味しません。目的のファイルに対応するバッファは、そのウィンドウに表示される場合がありますが、別のウィンドウ、おそらく別のタブ ページ、またはまったく表示されない場合もあります。

'switchbuf'ウィンドウでは、や を使用しても、開いているファイル間の移動が複雑になりすぎたり、単純になりすぎたりします:sb。主な原因は、基本的に同じこと、つまりバッファへのアクセスに対して 2 セットのコマンドを使用しなければならないことです。

Windows には、以下で説明するように用途がありますが、誰かのワークフローでバッファーを置き換えるだけの機能はありません。

ここでは、Vim のカラー スキームに取り組んでいます。2 つのウィンドウは同じバッファーの異なるビューです。上のウィンドウは、カラー スキームで使用されるカラー コードの表を含む参照用であり、下のウィンドウは作業用です。

ウィンドウはファイル プロキシとして設計されておらず、ファイル プロキシにすることもできません。ウィンドウは、バッファーのビューを提供するために設計された「コンテナー」または「ビューポート」です。それ以上でもそれ以下でもありません。

「タブ方式」

タブベースのワークフローでは、基本的に、以前のエディターで慣れ親しんだユーザー エクスペリエンスを模倣しようとしますが、Vim のタブ ページの性質を完全に無視します。この戦略は一般的に非常に非生産的であることを少し忘れると、Windows の場合と同様に、柔軟性を大幅に失うことなく、Vim を「1 つのファイル = 1 つのタブ」パラダイムに従わせることは不可能です。

上記と同じファイルで作業を続けると、タブ ラインは実質的にメリットがないのにかなりのスペースを占有します。すべてのファイルとすべてのタブは呼び出されるため、正しい場所にたどり着く自信が持てず、名前で特定のタブに到達することは不可能です。さらに、そのラベルは非常に役に立たないが完全に論理的である可能性があるという事実も加わりますjavascript*.vim...ファイル/バッファーをタブ ページに結び付ける実用的な方法がないため、タブ ページ/バッファー/ファイル間を移動する実用的な方法は基本的に 1 つしかありません。それは、循環です。3gt[Quickfix List]

そうです、私のタブラインには 8 つのタブしかありませんが、20 個のタブがあったらどうなるか想像してみてください。

1. 8 つのタブ ページで 8 つのバッファーが開きます(誤り)

   

2. 2 つの特定のタスク用の 2 つのタブ(右)

   

タブ ページは、1 つ以上のウィンドウを格納するように設計された「コンテナー」または「ビューポート」であり、それ自体もバッファーを格納するように設計された「コンテナー」です。

結論は

「Vim の専門家」(私がその一人であるかのように話せると仮定しましょう) は、タブよりもバッファを好みません。彼らは、Vim を設計どおりに使用し、その設計に完全に満足しています。

• 「Vim エキスパート」は 2、30、または 97 個のバッファーをロードしており、空間的な分散を処理する必要がないことに非常に満足しています。

• 2 つのファイルを比較する必要がある場合、または現在のバッファの一部を参照として保持しながら別の部分で作業する必要がある場合、「Vim エキスパート」はウィンドウを使用します。それが本来の使用方法だからです。

• 現在のビューを変更せずにプロジェクトの別の部分でしばらく作業する必要がある場合、「Vim エキスパート」はまったく新しいタブ ページを読み込みます。