Vim / EmacsはGUIテキストエディターよりも具体的な生産性の向上を提供しますか？
これは、トロールやフレームベイトなどを意味するものではありません。私は Vim をコンソールエディターとして数か月間使用していました（端末で設定ファイルを編集するために）が、私はそれを普通に我慢できないと思います。私はGUIテキストエディター（これは重要ではありません）を使用して、毎日Webアプリケーションを作成します。
私のGUIテキストエディターは、私の仕事に必要なすべてを行うことができると思います。それは両方のオートコンプリート履歴とまともな検索/置換を持っています。構文の強調表示、行番号、タブ付きインターフェイス、簡単なコピーと貼り付けなどがあります。現在のエディターにないのは正規表現のマッチングだけですが、正規表現の検索/置換を行うGUIテキストエディターはたくさんあります。
先ほど述べたように、Vim（またはEmacs）は、すべてのコンピューターにインストールされているという事実以外に、GUIテキストエディターよりも生産性の面で優れています。 Vim/Emacsでより優れた/より高速な、または既存のGUIテキストエディターでは不可能な特定のタスクが必要です。
Vimの場合：
Vimは、ほとんどのエディターよりも他のツール（シェルコマンド、スクリプト、コンパイラー、バージョン管理システム、ctagsなど）との統合が優れています。コマンドの出力をバッファにパイプする
:.!のような単純なものでさえ、ほとんどのGUIエディターにはありません。タブ付きインターフェイスは、Vim/Emacsが提供する「ウィンドウ」インターフェイスほど優れていません。複数のファイルを同時に並べて表示できます。画面上で見ることができるほど、変数名と関数シグネチャのメンタルブックキーピングを行うのではなく、心を自由に問題について考えることができます。
Vimの正規表現の力を過小評価しないでください。特定の列、マーク、カーソル位置、特定のクラスの文字（キーワード、識別子）などに一致するVim固有の拡張機能が多数あります。
統合された
diffおよびgrep（プラットフォームに依存しないため、コンピューターを変更するたびに新しいツールをダウンロードして学習する必要はありません）。（列を編集するための）ビジュアルブロックモードは多くのエディターには欠けていますが、それなしでは生きていけません。私はこれを使って仕事中の人々に衝撃を与え、w敬の念を抱きました。そうでなければ、誰かが手動で10分を費やしていたはずのいくつかのキープレスで編集を行いました。
複数のコピー/貼り付けレジスタ。クリップボードが1つしかない場合は、クリップボードの破壊を避けるために、奇妙なゆがみが発生します。する必要はありません。
Vimの元に戻す/やり直しシステムは無敵です。 Vimはスタックではなく元に戻すツリーを使用するため、何かを入力し、元に戻す、他の何かを入力しても、最初に入力したものを戻すことができます。他のほとんどすべてのプログラムでは、この状況では最初に入力したものの履歴が失われます。
Vimでは、テキストの移動、コピー、貼り付け、および削除が非常に高速です。コマンドはシンプルで、キーを1回押すだけで構成できます。慎重に面倒なマウスのハイライトとCtrl-Xを実行し、それらをすべて
da(に置き換えます（一致する括弧とその中のすべてのセットを削除します）。思っているよりも時間を節約できますカーソルの下の単語を検索する
*、コマンドを繰り返す.、開き括弧と閉じ括弧の間をバウンスする%などの小さなもの。リストするにはこれらが多すぎます。組み込みのスクリプト言語と強力なキーマッピングおよびマクロ機能により、エディターを必要な方法で拡張できます。たくさんのスクリプトがすでに書かれており、ダウンロード可能です。
よく見ると、他の編集者が持っている機能でさえ、Vimの方が優れていることがよくあります。すべてのエディターには構文の強調表示がありますが、VimにはSunのほぼすべてのファイル形式用の構文ファイルがあり、多くの場合、多くの構成オプションがあり、独自に記述するのは簡単です。多くのエディターがさまざまなファイルエンコーディングを処理しますが、Vimはファイルエンコーディングを設定し、それらの間で変換する非常に具体的で絶対確実な方法を提供します。 Vimについて私が感銘を受けた最初のことは、その時点で問題があった他のエディターと比較して、タブ/スペースのインデントオプションとUnix/DOSの改行がどれだけ完璧に処理されるかです。
これらのポイントの多くは、Emacsにも同じように適用されます（異なるが通常は同等に強力な方法で）。
（vimは私の毒です; emacsは同様の利益をもたらすと確信しています）
最大の利点は、マウスに触れる必要がないことです。
私にとって最も便利なのは、特定の文字または文字の組み合わせに前方に（またはその直前に）ジャンプするか、または2、3のキーストロークで後方にジャンプすることです。同じ条件で2回、または10回前にジャンプするのは、単に番号を前に付けるだけです。
編集を繰り返す必要がある場合は、その場所（2〜3回のキーストローク）にジャンプして、「。」を押します。最後の編集を繰り返します。同じ検索条件であれば、1回のキーストロークで前方へ（または後方へ）ジャンプする方が簡単です。
基本的に、短いリードタイムで、マウスをつかむために手を動かし続ける必要がないことを意味する10または20のキーボードショートカットを学ぶことができます。これにより、マウスをつかみ続けなければならない場合の3倍または4倍の編集動作/コマンドが得られます。
数日後、マウスに手を伸ばさなければならない（または<Down> 15回）、GUIエディターを使用している場合。
なぜVimに夢中になっている人が少ないのかといつも思っていました。実際のVimパワーユーザーのビデオをご覧ください。
https://www.youtube.com/watch?v=FcpQ7koECgk
現在の編集者が彼がしていることを実行できる場合は、切り替える必要はありません！ :)
また、これを読んでください http://www.viemu.com/a-why-vi-vim.html
ビデオを見てその記事を読んだ後、私はVIMを学び始めるしかありませんでした。 VIMに切り替えてから、他の何かを使用することを想像することはできません。
専用のテキストエディターの真の力の1つはマクロ編集だと思います。繰り返しは多くのプログラマにとって苦痛であり、適切なマクロを書くことは境界線上で楽しいものです。キーボードを使用してすべてを実行していない場合、マクロを作成するには、既に使用しているコマンドを使用するのではなく、追加のコマンドセットが必要になります。
私はviのキーバインディングに中級ですが、全体的にEmacsを好みます。これらのエディターに熱心な支持者がいるのは、提供する編集モデルが新しいシステムよりも強力であるためです。拡張機能を使用していなくても、「viキーバインド」または「emacsキーバインド」を提供するだけでは不十分です。またはemacsまたはviのカスタマイズ。
Emacsのモデルについてのみ説明します。これは、私が最もよく理解しているからです。今日のテキスト編集の一般的なモデルには、テキストのバッファーが含まれます。このバッファーでは、テキストをシステムクリップボードに挿入、削除、選択、切り取り/コピー/貼り付けできます。
もちろん、Emacsバッファーはこれらの操作をサポートできます。表示されている各ウィンドウのカーソル位置の追跡に加えて、作成された「マーク」も追跡します。 「ポイント」（カーソル位置）と「マーク」の間のテキストは「リージョン」と呼ばれ、主流エディターでの選択にほぼ対応しています。
違いは、Emacsはマークがマークリングで設定された最後のいくつかの場所を追跡し、キーストローク（または構成に応じて2つ）でそれらに戻ることができることです。特にバッファ内の位置を変更する多くのEmacsコマンドが古い位置にマークを設定するため、これは非常に便利です。例は、Pythonモジュールを編集していて、インポート文をファイルの先頭に追加する必要がある場合です。バッファの先頭に移動するためのキーストローク（Alt- <）セットインポートステートメントを追加します。Ctrl-uCtrl-Spaceを押すと、元の場所に戻ります。これを繰り返して、前の位置に戻ることもできます（追加中にテキストを選択する必要があるかもしれませんそのインポート文。）
他の（そしてより有名な）Emacsの違いはキルリングです。バッファーからテキストを削除するためのキーストロークのほとんどは、キルリングにテキストを保存し、「yank」コマンド（Ctrl-y）で呼び出すことができます。基本的な機能は、後続のyankコマンドが古いキルテキストを取得することです。したがって、テキストの複数のセクションを連続して削除してから、順番に取得できます。また、ヤンクの後にAlt-yでキルリングを循環し、取得したテキストを削除して、リングに次のエントリを挿入することもできます。
Emacsには1978年にこれらの機能がありました。これらをある程度採用する唯一の他の主要なシステムはNeXTSTEPです（そして現在Cocoaに継承されています）。他のツールは、特定のタスクにより多くの機能を提供し、Emacs LISPよりも使いやすい言語で拡張でき、より優れた視覚的インターフェースを備えています...しかし、Emacsはテキスト編集で優れています。そのため、使用方法がわかれば、終了するのは非常に困難です。
これは厳密な特定のタスクではありませんが、RSIに苦しんでいる可能性があるの人にとっては、手がvimでキーボードから離れないという事実はほとんど価値がありません。私は実際に仕事でマウスを左利きにしたのは、マウスに手を伸ばすために手を動かさずに済むためです（自宅のキーボードにはテンキーがないため、右に置いておくことができます）。
もう1つの小さな利点は、オリジナルのviであるIIRCが、非常に遅いリモート接続でのファイルの編集を高速化するように設計されていたことです。確かにそれは今日ほどではありませんが、接続速度が遅い場合は、GUIテキストエディターを実行して応答できるようにしてください。
私にとって大きな生産性は
- キーボードからほとんどすべてのことができます。
- 強力なマクロ。
- 9つのOSを使用する20年のキャリアでは、基本的なキーボードバインドは変更されていません。ほぼすべてのシステムに飛び乗ることができ、すでにエディターの方法を知っています。
- テキストエディタに必要な機能は、すでに追加されています。
私が実際に vimについて好きなことの1つは、 "repeater"コマンドです。基本的に、.コマンドモードでは、最後のアクションを繰り返します。これは、GUIにはないことが多い「プログラマーテキストエディター」にある非常に優れた機能のほんの一例です。
私の経験では、vimとemacs（私はvimの人ですが、emacsは確かに似ています）が提供する主な生産性の向上は次のとおりです。
can現代のIDEが提供する機能（ワンキープレスの編集-ビルド-実行サイクル、インラインドキュメント、タブ補完など）を持っていますが、持っていませんする必要があります 。生産性の向上は？見たいだけ見ます。私の経験では、IDEはtoo much情報（すべての種類のブラウザー）を示していたため、人々の生産性を高めませんでした。この「余分なパワー、必要なときに-しかし、すぐに」は、非常に生産性が向上します。
エディターはプログラマーの間で非常に人気があります。つまり、利用可能なスクリプト、書籍、ユーザーグループの膨大なリポジトリがあります。
私の経験では（ここではvimしか話せません）平均的なvimユーザーはかなり良いソフトウェアエンジニアです。なぜそれが（または単に幸運なのか）わかりませんが、おそらくemacsやvimのような「古い」ツールに慣れることの障壁をとった人々は、適切な献身を持っています（そして、そのような他の人々と接触します） ）。たぶん、これらのエディターの間接的な影響ですが、他のvim（またはemacs）の人々との付き合いがあります。 IRCは、同じ人があらゆる種類のソフトウェアエンジニアリング（またはコンピューターサイエンス）の問題にも非常に興味を持っていたため、非常に興味深いことが判明しました。これらのエディターは、ある種の人格を引き付けるようです。 -）
小さなプログラムに軽量のemacsクローンを使用することで得られる「生産性の向上」は、グリースを塗った稲妻のように起動することです。通常、Visual Studioが「サンドボックス」ソリューションのロードを完了する前に、C＃で簡単なテストプログラムを実行できます。
もちろん、Visual Studioを開いたままにしておくこともできます（またはanother VSで作業している場合はVSを開いたままにします）が、しばらくアイドル状態のままにするとスワップアウトされます。
かなりのサイズの場合-または、使用しているAPIがよくわからない場合-IDEが今後の道です、IMO。
私はウィンドウにgvimを使用しているため、技術的にはGUIテキストエディターですが、vimです。
生産性の向上のために、私は見つけます：
- 私はマウスを使用する必要はないので、高速です。
- 検索、置換、コピー/貼り付けなどはすべて、vimキーバインドとマウスの動きのほうが高速です（学習曲線を超えた後）
- 前のコメントで述べたように、RSIは大幅に削減されています。私がvimに移行して以来、私の手首は私に感謝しています。
- 軽量で速い
ご存知のように、viの場合、挿入モードとコマンドモードが必要だと思います。カーソルや特別なキーに依存できなかった時代への先祖返りのように思えるかもしれませんが、それが本当に意味することは、多くの強力なモーションおよびテキスト操作コマンドが最小限のキーストロークであるということです。生産的なコーディングは、バルクテキストエントリ（「近代的な」エディタのデフォルト）ではなく、大量のテキストのバーストとそれに続くかなりの小さな調整、さらに長いブラウジング期間です。
これは、高レイテンシのキャンパスネットワーク上でviを個人的に使用するために私に前面に来ました。応答の前に10または15文字を簡単に取得できます。 viを使用すると、これらのコマンドがどこに残るかを快適に予測でき、ほぼ通常の速度で作業できます。このねじれた専門知識は、通常の条件下で継続的な利点です-一定のグラフィカルフィードバック専用の視覚的脳力が低下します。
一般的な*および＃Word検索アクセラレータは、コードをめくるのに最適です。そして、括弧を一致させるための％は非常に便利です。確かに、ctl-]に比べてほとんど同じようには見えませんが、キーストロークの半分が加算されます。
個人的には、winviを使用します。これは、vimにもあると確信している大きなものをいくつか追加します。 16進モードにすばやくジャンプすると、多くの「何が起こっているのか」というテキストの問題が解決されます。また、行末の完全に柔軟な処理は、テキストエディターの期待される機能になった天の恵みです。最後に、内容に関係なく任意のファイルを開くことができます。これは、最初のオーダーのエリートハッキングスキルに相当します。
Unixでは、プログラムの出力をすばやくキャプチャしたり、外部コマンドを使用してファイルのセクションをフィルタリングしたりできます。非常に強力ですが、まだ十分に活用されていない機能だと思います。
私は頻繁にVimを使用しています。私にとっては ltraEdit に置き換わるものではありません。たくさんのポジティブな点がリストされているので、私はグレインに逆らい、Vimの不快感をいくつかリストアップすると思います。
- 弱いFTP処理。私は多くのサイトを「ソート」しますが、リモートFTPサーバー上のファイルを簡単に参照および編集できないことは、私にとって大きな欠陥です。 NWReadはnotで十分です。
- Linuxを悩ませていると思われる一般的な端末の問題から引き継がれたコンソールの奇妙さ。私は通常 PuTTY を使用してLinuxボックス（Ubuntuを実行）に接続し、何らかの理由で、矢印キーが挿入モードでA/B/C/Dにマップします（およびカラーサポートの問題全体） ）。 gVimでは、ctrl-tabは「bn」easyにマッピングできますが、コンソールモードではマッピングできません。そのような問題はたくさんあります。
- 検索/置換オプションは非常に弱く、インターフェイス上は賢明です。すべてを1行に入力するだけでは十分ではありません。 UltraEditは、実際の正規表現のサポートがはるかに弱い場合でも、最終的にはより多くの力を与えると言った、はるかに手の込んだ対話を感じています。
- 米国のキーボードレイアウトへの依存が強すぎる。 `などの主な機能に使用される多くのキーは、私のデンマーク語のキーボードレイアウトに印刷されていません（そして、$と同じように、厄介に配置されています）。いくつかの機能を使用するのはかなり厄介です。
大きな利点の1つは、vimエディターの拡張性だと思います。 CVSで何かを動作させたい場合は、CVSMenuプラグインを取得してエディターに追加し、その機能を取得します。
構文の強調表示、特定のファイルでの動作なども同様です。vimではあらゆるものを調整できます。
GUIタイプエディタで簡単にできるかどうかはわかりません。
リモートデスクトップは、ネイティブWindowsアプリケーションのみをすばやく表示します。 UNIXで開発するためにEclipseを使用しようとしました。そして、あなたは何を知っていますか？それも不可能でした。
2番目の理由は、VimとEmacsを拡張して、DBブラウジングからプロジェクト固有のすべてのタスクを特別な方法で実行して、独自のメタ言語を強調表示および自動補完できることです。
私は何年もの間、Emacsの卑劣なユーザーでした。しかし、実際にそれに入ることはありません。その後、Clojure（私の最初のLISP）を学び始め、ParEditを発見しました。
そして、それは私の心を吹き飛ばしました。
（いくつかの例についてはこちらをご覧ください： https://www.youtube.com/watch?v=D6h5dFyyUX ）
LISP + ParEditは、これまでで最も素晴らしい編集体験です。他に近いものはありません。 LISPはもはや書くのが面倒な言語ではないので、いらいらする愚かな括弧のバランスを取ることを心配せざるを得ません。 ParEditを使用すると、同じツリー変換（丸lurみ、バーフ、分割、結合）が制御構造とデータ構造のすべての場所で機能するため、一貫したLISP構造は大きなボーナスとなります。そして、ParEditは、私が愚かな間違いを犯すのを防ぎます。構文エラーを起こすことはほとんど不可能になります。
また、Eclipseとは異なり、これは常にバックグラウンドで実行され、プロセッサを焼き尽くす面倒なリアルタイムチェックではありません。費用はかかりません... ParEditは、要求されたときに正しい構造変更を行うだけです。
（一般に、Emacsは必要なだけ高速です。Eclipseとは異なり、グルーで入力するようなものです。）
次に私が発見したのは、ヤスニペット（ http://emacswiki.org/emacs/Yasnippet ）でした。繰り返しますが、以前はこのようなものは使用しませんでした。定型文を追加するための単なるマクロではなく、動的でナビゲート可能なフォームです。
最終的な喜びは、このことを自分で拡張して、これらの高レベルの生産性ツールをさらに増やしたい場合、LISP自体の力を活用できることです。
VIMでの記録と再生は、GUIベースのツールで見つけることはまずありません。
また、 自動インクリメント/デクリメント は、プログラムを作成せずにデータ生成機能を提供します。
（私の経歴はVisual Studioと他のIDEで数年、その後15年のVim、Emacsでの最近の6か月です。）
Longevity— Vim/Emacsは [〜＃〜] foss [〜＃〜] であり、数十年前から存在しています。それらの使用は衰えず、機能が大きく壊れる/消える/変わることもないので、たった1人の編集者の習熟に基づいてキャリアツールボックスのコア全体を構築することに頼ることができます。
端末でのリモート/ユビキタスアクセス—どちらもリモートファイルを編集するための優れたシステムを備えていますが、ログインした任意のシステムにインストールすることもできます。
REPL駆動型開発—両方ともREPL you'reたとえば、 [〜＃〜] cider [〜＃〜] で提供されるほど強力な反復開発に遭遇したことはありません。
Linting—コンパイラに組み込まれていようと外部ツールに組み込まれていようと、使用している言語にはおそらく linting ツールがあります。これらはEmacs/Vimとシームレスに統合され、コーディングの遅れをほぼリアルタイムで表示します。
ニーモニックコマンドの文法—両方とも学習に時間がかかりますが、これらのエディターは、数千のコマンドに少数のコマンドでアクセスし、さらには記憶するための有名なシステムを備えていますキーストロークとキーの組み合わせ。こうすることで、マウスを使用する必要がまったくなくなります。
組み込みヘルプシステム—多くの言語とそのAPIのオフラインドキュメントは、これらのエディターに組み込まれているのが一般的で、同様に簡単な方法でアクセスできます。それらが備えている広範かつ包括的なヘルプシステム。自動補完は、ほとんどの一般的な言語に追加されています。さらに、ほぼすべてのヘルプトピックに関する豊富なディスカッションヘルプがあります。
Navigation—タグ、paredit-likes、マーク、ウィンドウ、タブ、vim-Rails ' jumping 、およびさらに多くの組み込みインス。
Package managers/repositories— Emacsにはいくつか（elpa、melpa、marmalade）があり、Vimも優れています（vundle、pathogen、 など） ）。これらに匹敵するものを提供するIDEの周辺のコミュニティは知りません。 package-list-packagesのパッケージが5,000個以上あります。
単なる編集を超えて— Emacsは、ニュースを読んだり、ウェブを閲覧したり、電子メールを管理したり、スプレッドシートを編集したり、プレゼンテーションを作成したり、あらゆるものを整理したりすることができます。
その他すべてを統合—デバッガ、ブラウザの同期、コンパイル、シェル、テスト実行。
無限にカスタマイズ可能— ElispはEmacsを拡張/修正するための非常に強力な言語です。 VimLはVimと同等です。両方に書かれた本があります。色のテーマと動作を微調整してください！
2003年以降、vim/emacsはプログラマやC＃ユーザーとして使用されることが多いため、この偏見から不公平な比較を行うのが適切です（別の方法として、vim/emacsのVisual Assist XとC++のVS C++があります）。
C＃およびVisual Studioの場合：
この行のキーストロークの数を数えただけです。
public List<string> Names = new List<string>(); // 3 3 3 1111111111111 211 =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's // (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want) // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-completeコードにジャンプするためのemacs機能について読みました。私はそれがまさにそのような機能を持っているとは思わない。ただし、同様の機能があります。これがVSの欠点です。多くの小さな機能がありますが、時間が経つにつれて機能しなくなります。最後に、ジャンプ機能が機能しないことを確認しましたが、それは数年前のことです。 VSは、私が代わりに使用している新しいグラフィカルジャンプ機能を導入しました。マウスまたはタッチが必要です。
ここでemacs/viが勝ちます。コードを何度も飛び回る必要がある場合、このためのVS機能は存在しないか、十分にテストされていません。
マウスベースのGUIナビゲーションの問題は、
a）非常に静的な位置に座っているのと同じように、もしそうなら、マウスは指を静的な位置に置く傾向があります。手首の痛みは、トラックボールへの変更でなくなりました。私は最初に垂直マウスを試しましたが、問題に対して何もしませんでした。
b）私の理想的なキーボードには、テンキーのない2列のファンクションキーがあるので、トラックボールを近くに配置でき、ジャンプ距離がより耐えられます。
しかし、最終的には、いくつかの特定の場所の間をジャンプしたい場合は、「マークリング」がより効果的であることは明らかです。 VSはそれらの線に沿って何かを持っています...最後に私はそれを使用しました、それはただ確実に動作しませんでした...
c）そして、各リリースで壊れる小さな機能がたくさんあるので、これはVSの欠点です。
この「クローズドソース」問題の解決策：VS全体をC＃で記述し、ソースをリリースせずにコンパイルされたコードを修正/編集（実行時に、オプションとして次回起動時にロードされるパッチとして変更を保存）できるようにします。これは、デコンパイラーにコードを入力したときの状態で出力させることで実現できます。ネイティブコンパイラーの動作から180度離れています。バイナリがソースコードになり、代わりにこの.csファイルや.exeファイルなどの混乱が発生します。既にこれを実行できるサードパーティのツールが存在するため、C＃exeの「改造」はかなり簡単ですが、論理的な結論：.exeおよび.dllに偶数のコメントを含めます。コンパイル済みのC/C++アプリと比較すると、ファイルはまだ小さいままです。最適化？事前に最適化されたコードを含めることもできます。アプリの実行中にmodderがexeを変更すると、変更されていない「AST」とそれに付随する最適化されたバイナリが再びプラグインされます。C＃コンパイラと同じ考え方ですが、さらに詳しく説明します。次のステップ：OS全体をこの言語で記述します。これにより、Windowsがクローズドソースであっても、ソースコードがすべてのバイナリに付属しているため、簡単に変更できます。環境の設定、コンパイル、リンクはありません。実行中にOSを変更するだけです。近いアナロジー：Common LISPでWebブラウザーを作成した場合、Webブラウザーを停止せずに編集し、ブラウザーと同じ言語でWebページを構築できます。
すべてのコンソールベースのエディターがGUIエディターより優れている点の1つは、 screen または tmux などのターミナルマルチプレクサーで実行できることです。なぜこれが良いのですか？
- 1つのGUIから別のGUIにマウスやalt-tabを使用して切り替えるよりも、1つのターミナルマルチプレクサコンソールから別のコンソールに切り替える方が高速です。これは、コンソールに名前を付け、名前の数文字を入力することでコンソールに切り替えることができるためです。
- エディタセッションがターミナルマルチプレクサのコンソールにある場合は、どのマシンからでもアクセスできます。自宅で仕事をする必要がある場合は、ボックスにsshし、既に実行中のターミナルマルチプレクサをsshセッションに接続し、仕事を辞めたときに中断した場所に戻ることができます。