私のターミナル活用法
引用元：https://news.ycombinator.com/item?id=44356646
これ最高だね！俺もこういうワークフローを10年くらいかけて改良してるんだ。カスタムレイヤーはメンテが大変だから、できるだけ減らそうとしてるよ。Stock Vimなら（tmuxなしでも）、rg --vimgrep restore_tool | vim -c cb -みたいに、この記事のほとんどができるんだ。vim -c cb -は俺のお気に入りの機能なんだけど、全然使われてないし話されてないのが不思議だね。( rg検索を再実行したくない時とか、結果をVimで開く前にターミナルで分析したい時があるんだ。その時は、前のコマンドの出力をコピーするカスタムtmuxコマンド（この技だよ: https://ianthehenry.com/posts/tmux-copy-last-command/）を使って、それをtmux saveb - | vim -c cb -みたいにVimに送ってる。) URLがあるから200字超えてるけど、許してね！
10年前に massive なVim設定を全部捨てて、毎年1〜2行ずつ超シンプルなvimrcを組み立て直してるんだ。古いソフトのデフォルトにはたいてい理由があって、変える前に理解しようとするべきって意見に、完全に同意だよ。
それは、当時のデザイナーがuniversally great だったらの話でしょ？そうじゃないから、デフォルトはuniversally badなんだよ。だから、固執して理解しようとするのは時間の無駄だし、bad heuristicだね。例えばVimのhjklがデフォルトなのは、デザイナーの物理キーボードに矢印が描いてあっただけ。深い思考なんてなくて、理解してもuseless triviaだよ。
誰かVimを俺に売り込んでくれないかな？どう見てもtiling window managerみたいなテキストエディタにしか見えないんだ。プラグイン入れてもKateとかJetbrains IDEsより機能少ないし、前に試した時はターミナルエディタなのに遅かったし。ターミナルでテキスト編集するならmicroの方がマウス使えるし、普通のOSのキーバインドだし良いじゃん。Vim使いをinsaneとは思いたくないけど、niche nerd thingとしか思えないんだよ。
それはかなりharshだね。デザイナーがperfectじゃなくても、デザインがuniversally badってわけじゃないでしょ。あなたの例で言うとさ、hjklがなんでそのキーなの？って言うけど、ホームポジションにあって、touch typistsの右手のresting fingersの下に来るんだよ。それって急にconvenientじゃない？
＞ defaults in old software are almost always there for a reason
ホームポジションに指を置くのは、keyboard-first navigationにとってgreat designだよ。ソフトウェアデザインは歴史的な経緯があるから一理あるけど、古いデザイン＝bad designって決めつけるのは間違ってるね。変わってない良いものもあるんだから。
＞ Keeping your fingers on the home row is great design for keyboard-first navigation.
指摘されてるけど、これは間違い。Vimのデフォルトはこのロジックに従ってないんだ。例えば、単語単位で戻る 進むみたいな一番よく使うコマンドはhome rowにないし、name-based mnemonics っていう違う原則に従ってる。厳密に言えばhjklだってそうだよ。矢印が描いてあったからで、デザイナーが良いデザイン原則に従ったわけじゃない（物理的な矢印自体はその原則かもしれないけど、resting keysから外れるのはまだ謎、ASCII H codeがbackspaceと関係あるかも URL: https://news.ycombinator.com/item?id=3684763 ）。変わらない普遍的なことって、適当な奴らが盲目的にデザインしてもuniversally greatな世界は作れないってことだよ！URLがあるから200字超えてるけど、許してね！
指摘されてる通り、これは間違いだよ。touch-typistsが本当に欲しいのはjkl;だね。だってhome keyはjだから。これはvanilla vimだと絶対に必要な設定変更なんだけど、残念ながらね。
なんで memory commit なんてするの？ git commit してgit cloneすればいいじゃん。（俺はdotfilesをリポジトリに入れてるよ）。vimrcをミニマルにしたい気持ちはわかるけど、実用性も必要でしょ？lang-serversみたいなプラグインは絶対に必要だよ。Vim自体の開発が進んで、俺のvimrcからいくつか設定が不要になることがあるんだけど、それはいつも嬉しいね。
”rg –vimgrep restore_tool | vim -c cb -” ってコマンド、使ってみたいと思ったんだ。
でもね、僕の環境じゃ動かないんだよ。
Vimは処理中にエラーがあったって言うし、バッファを保存してないって出るんだ。
rgの結果は表示されるんだけど、そこからどうやって該当箇所にジャンプすればいいの？
そうだね、ホームポジションの休憩位置にはないけど、よく実行するコマンドなら十分近いよね。
キーマップを作るのは、覚えやすさと使いやすさの最適化問題だよ。
Vimのコマンド配置は完璧じゃないし、個人的には$（行末移動）が一番ひどいと思う。よく使うのにちょっと遠いんだ。
でもね、今でも使われてる古いソフトを使い始めるときは、ちょっと謙虚になった方がいいよ。
昔のソフトやデザイナーが必ずしも良かったわけじゃなくて、今も使われてるってことは、きっと何か利点があるからなんだ。
だから、まずはデフォルトを学んで、理解してから変更するのがいいよ。
コメント31865さんへ。
コマンドの cb を cb! に変えてみて。rg --vimgrep restore_tool | vim -c cb! -
あと、デフォルトでクイックフィックスリストを開くならこっち。rg --vimgrep restore_tool | vim -c cb! -c copen -
クイックフィックスの使い方について詳しくは :h quickfix を見るといいよ。
コメント31866へ。
＞よく使うなら十分近い
そうだね、wとかbもホームポジションから完全に離れてるけど「十分近い」よね。
＞今使われてるってことは、それなりに理由がある
この原則と、まずデフォルトを学べって結論がどう繋がるの？
その結論を支持するのに、どうやってこの原則を使うの？
あなたの結論間違ってない？
昔、賢い先輩に言われたんだけどね、「アプリのデフォルトを素早く快適に使えるようになれば、どんなシステムでも同じようにサクッと快適に作業できるようになるよ」って。
なんか Zen って感じだよね。すごくいいアドバイスだと思うよ。
＞そして前回本気で試した時、遅かった。ターミナルテキストエディタとしては意外だね。
それ、たぶん設定がおかしかったんじゃないかな。
素の Vim より速いエディタってなかなかないし、外部プラグインのせいで変なパフォーマンス問題が出ることはたまにあるんだよね。
コメント31872さん、多分僕もそう思う。
VimでIDEプラグインいくつか使ってたから、それが原因だったんだろうね。
IDEみたいな機能がないと、ぶっちゃけテキストエディタって必要ないんだよね。
MicroならデフォルトでLSPサーバーも使えるし、これでかなりいける。
そこから Kate とかちゃんとした IDE に行く感じかな。
これってさ、’vim -q ＜（ripgrep –vimgrep restore_tool）’と一緒か似てる？
個人的にはJとKの向きが逆な感じがして、いつもどっちだっけって思い出しちゃうんだよね。タッチタイピストでもKは下、Jは上であってほしい。左上から右下に書く僕たちの感覚だと、↑と←、↓と→がセットになる方が理にかなってると思うんだ（←↓↑→）。←↑↓→の方がずっといいな。一番使う下方向（↓）がニュートラルな指の位置に近いし、何より’戻る’と’進む’のキーがまとまってるからね。
U I J Kとか（↑ ↓
← →）みたいに二列に分かれててもいいくらいだよ。（個人的には、カーソルキーが遠くて不便な時があるから、AutoHotkeyでCaps LockとのコンボでIJKLにWASDみたいなグローバルな矢印マッピングを設定してるけどね。）
それは客観的に見たら全然間違った結論じゃないよ！ただ、それを’間違ってる’って言ってもいいけど、ちょっと考えればその言葉にはたいして重みがないってわかる。
せっかく面白い議論なのに、不必要な威圧感をちょっと薄めたかっただけなんだ。
正直、僕はいつも全体的な設定やメンテナンスの負担を減らすために、価値の高いアイデアのデフォルトを学ぶことにしてる！
それに、他の人に作業内容を伝える時も、デフォルトが定着してて使いやすいから、そんなに説明しなくて済むんだ。
最近はどこでも可能な限りデフォルトを使ってるよ。こうすると、新しい環境をセットアップする時に大量の設定をしなくて済むんだ。
あと、デフォルトってすごく理にかなってることも多いって気づいたんだよね。完璧ではないかもしれないけど、十分すぎるくらい。
その結果、かなり合理的に素早く作業できるようになるんだ。
それに、スキルを頻繁に再学習する必要もなくなったよ。
とにかく、ここでは同意しない余地はたくさんあるけど、誰かの結論が’間違ってる’っていう考え方以外ではね。
＞（’vim -c cb -’はVimで一番好きな機能なんだ。あんまり使われたり話されたりしないのが不思議。）
それ何するの？’ls ｜ vim -’と’ls ｜ vim -c cb -’を試してみたけど、すぐには違いがわからなかったな。
そうなの？わざわざ自分を縛るべきなのかな？ツールを最大限に活用してもっと仕事をこなす方が良いアドバイスに思えるけどね。
＞どんなシステムでも同じくらい素早く快適に使えるようになる。
他のシステムってどれくらいの頻度で遭遇する？それに、たまにしかSSH接続しないような場所でさえ…（本番環境でライブでコードを編集する…？）そんなにたくさん編集するの？（僕は自分のVimをかなりカスタマイズしてるけど、ストックのVimとかnanoが入ってるリモートシステムで困ることはないよ。edは別の話だけど。）
でも、もし大量に編集する必要があるなら…sshfsとローカルのVim/ターミナルでいいんじゃない？でもこれって本当に稀なケースだから、’一般的なケースに最適化すべき’っていう話の一つに思えるんだよね。これは一般的じゃない。
僕はあのキーバインディング（HJKLのことかな？）が好きだよ。垂直移動の方がよくするから、そっちに一番強い指（親指以外で）を使いたいんだ。それに、右移動の方が左移動より多いから、左移動するために指を動かすのは気にならないな。
’cb［uffer］’は現在のバッファをコンパイルバッファとして処理する機能だよ。grep形式にマッチする行（つまり、最低でも＜path＞：＜line-number＞：＜column-number＞で始まる形式）を見つけて、quickfixリストに入れて、最初のマッチした場所にジャンプするんだ。
例えば、君の例だとlsはgrep形式の行を出力しないから何も起きないんだよ。だから、grepの出力をパイプで渡してみて（grepでその形式にマッチさせるには行番号と列番号のフラグが必要だよ。だから上の例では–vimgrepフラグを使ってる）、あるいは’ls ｜ sed ’s/$/：0：0/’ ｜ vim -c cb -’を試してもいいよ。これはlsの出力をハックしてgrep形式にするもので、たまに便利だよ。
（上の説明はもう一つの便利なヒントを示唆してるんだ。grepの解析は’cb［uffer］’ができることの一部で、コンパイル出力も解析できるんだ。例えば、’gcc foo.c ｜ vim -c cb -’とすると、プログラムの最初のコンパイルエラーにジャンプして、残りのエラーはquickfixリストに入れてくれるよ。）
コマンド履歴（かそれに類するもの）を見て、毎日新しいzsh設定（か他のドットファイル）を追加してくれる生成系LLMスクリプトがあったら最高だな。しかも、一日の最初のセッション中に画面にパッと表示される信頼できるmotdみたいな画面で、何が追加されたか説明してくれて、一日かけてそれを試して残すか決められるようにしてくれるの！
要は、大量に新しいことを一度に’学ぶ’ようなセッションじゃなくて、毎日新しいことを試させてくれることで、僕の環境をゆっくり’進化’させてくれる感じ！
quickfixウィンドウを垂直分割で開く方法を探したんだけど、何も見つからなかったよ。何かアイデアある？
記事のgrepの使い方は、自分と似てるけど、-qオプションの挙動とか細かいとこが違うね。
いいターミナル環境だね！tmux、fzf、rg、zoxide、nvimとか使ってるんだね。atuin、starship、bat、glowとかもおすすめだよ。特にatuinは超便利。昔はツール使いこなせるのがプログラマーって感じだったけど、VSCodeとかLLMも大事になったよね。でも、ツールは今も最低限のスキルだよ。LLMもミスるから、magitとかも必須。ストックのCursorより速いって思うなら、LLM使いこなす動画作って見せてよ。
プログラマーって開発環境の設定だけが全てじゃないよ。Unixのexエディタ使う熟練者もいれば、すごいIDEでもダメな初心者もいる。ツールも大事だけど、決定的な差にはなりにくい。LLMで変わるかもだけどね。スタートアップの失敗は、使ってるツールじゃなくて、共同創業者の問題とかPMFが見つからないとか、もっとデカい理由からだよ。
”プログラマーは開発環境の設定が全てじゃない”って？プログラミングは創造だよ。良いクリエイターはツールや技術を磨くのを楽しむものだ。プログラマーもツールに投資するけど、それはただ楽しむから。ツールに興味ない人は、プログラミングそのものへの情熱が足りないから、たぶん強いプログラマーじゃないね。
良いプログラマーがツールに投資するってのが絶対って変じゃない？逆に、ツール設定に時間かけない方がプログラミングに集中できて良いって見方もできるし。完璧なセットアップ作りを楽しむのはいいけど、それが強いプログラマーの条件だとは思わないな。他のコメントみたいに、生産性のベースラインは低いのかもね。
もっとコメントを表示（1）
この議論、ホント変！熟練した職人がツールを極めるのは当然でしょ。GitHubのリストにあるツールを少し設定するだけで数週間で5%も効率上がるなら、ヤバくない？vimとかemacsを極めた人はVSCodeユーザーを余裕で”スモーク”できると思うよ。VSCodeが勝ってるのは使い始めやすさだけ。ツールの習熟って複利で効くんだよ。BrooksのMythical Man Monthでも、技術力あるマネージャーと少人数のチームが良いって言ってる。ハッカーはチームとマネージャーと上手くやるのが大事。
まあね。開発環境に時間かけてちょっと差をつけるのもいいけど、ソフトスキル学んで他のエンジニアをごぼう抜きする方が良くない？みんな技術ばっか見てて、ボトルネックがそこじゃないって気づいてないんだよ。
”良いプログラマーがツールに投資するのが絶対じゃない”って？俺はそんなこと言ってないけどね。でも、有名プログラマーのリスト見てみ？Donald Knuth、Rob Pike、Ken Thompsonとか、みんなヤバイツールビルダーでもあるんだよ。最高のプログラマーには、そういう人が多いってパターンは明らかだろ。
ツール使いこなすのが生産性に与える影響、買いかぶりすぎだよ。良いツールは便利だけど、それで”より良いプログラマー”にはなれないし、他の人を”スモーク”とか無理。コード書く時間より、考えて、設計して、話して、協力する時間の方が圧倒的に長いんだから。コードの読み書きはボトルネックじゃないよ。システム理解して、それをコードにする方法を考えるのが大事。機械的な部分は今やLLMがやってくれるしね。
”tmuxとかfzfとか使ってるんだね。atuin、starship、bat、glowとかもおすすめだよ”って言ってるけど、君がリストアップした名前のほとんどを知らない人からすると、これ全部 absurd に聞こえるだろうね。
プログラミングの本質はツールの設定じゃなくて、創造することだよ。画家とか陶芸家と同じで、大事なのはツールじゃなくて作品を作ること。ツールに詳しくなるのはいいけど、それが全てじゃないんだ。マリア・ポベカ・モントーヤ・マルティネスみたいに、シンプルなツールでも素晴らしいものは作れるって話。
OPの言うことは分かるよ。昔のプログラマーは自分のスクリプトとか設定とか、道具箱みたいに持ってあちこち移動してたんだ。職人が自分の道具を持って仕事に行くのと同じ感じだね。
ソフトスキルとツールは対立しないし、両方大事だよ。ツールを突き詰めることで問題解決能力も上がるんだ。クヌースとかリーナスみたいな伝説的なプログラマーも、ツールの開発にめちゃくちゃ力を入れてた。ソフトスキルだけでずば抜けたプログラマーなんていないんじゃないかな。俺は彼らみたいになりたいし、ツールいじりはそれ自体が楽しいんだ。ツール磨きを“卒業”する気はないよ。
俺もずっと自作ツールとか設定を使ってるから、慣れない環境は最初は大変だよ。自動化で時間が浮くこともある（grepの出力クリック化とか）。でも、ツール磨きに時間をかけるのは、使う時間や学ぶ時間を減らすことにもなる。最高のツールも使う人が未熟だと意味ないし、何時間もかけて自動化しても少ししか得しないこともある。昔のカスタマイズは今使わないけど、やったスキルは残ってるね。
ツールにこだわりすぎだよ。マジでデキる開発者は、何もない“naked”な環境でも速く結果出せる。いいツールは助けになるけど、ちょっとした改善でしかないし、個人的な楽しみの面が大きいんじゃない？どのIDE使うかで仕事の成果が大きく変わるなら、まだまだこれからだね。“knowing your tools”がプログラマーであることじゃなかった。俺が見た最高の開発者は、more／grep／viと思考だけで凄い仕事してたよ。価値を生むのは考えることだって。それはLLM使っても同じさ。
前のコメントには全く同意しないね。あの有名人たちは“devs for devs”（開発者向けにツールを作る開発者）だから、ツールに時間かけたのは製品のためなんだ。個人のツール改善は自分にしか影響ない。ソフトスキルだけでずば抜けたエンジニアはいるか？最高のエンジニアはツールは当たり前に使うけど、細かい改善よりお客さんとか他のチームと話したり、ドメイン知識つけたりするのに時間使うよ。ゲームチェンジャーになるようなツールには投資するけど、vim設定とかはしない。結局、ドメイン理解してコミュニケーションできる人が、最高の技術スキルだけの人より良いもの作るんだ。これは“プログラミングからの成長”だと思うな。でも、自分が幸せならそれが一番だよね！
コマンドのリストいいね！fdとatuinもおすすめだよ。fdはfindの代わりに使いやすいし、atuinは昔のコマンドを探すのにめちゃくちゃ便利なんだ。CLI作業がすごく快適になるよ。
なんと！このコメントに書かれたツールが数時間後にはHacker Newsのトップページに載ったんだって。コメント欄で触れたものがこうして話題になるなんて面白いね。この場所、最高だよ！
ツールの最適化より創造が大事って話、分かるよ。芸術とか工芸もやるのが本質だもんね。でも、ツールをいじること自体がクラフトな場合も結構あるんだ。プログラミングツールを作ったり設定したり直したりするのは、まさにプログラミングそのものだよ。コード書いて、問題解決して、設計して…本業と同じスキルを使うんだ。ツールを理解して自分で作ることで、もっとシステムのことが分かるようになるしね。ツールの作業は、君をもっと良いプログラマーにしてくれると思うよ。偉大なプログラマーもツールをすごく大事にしてるからね。
言いたいこと、全然分からないんだけど。プログラミングの本質はツール作りだよ。最高のプログラマーも最悪のプログラマーもツールは作る。ターミナルの設定アプリ作るのと、TeXみたいの作るのを本気で比べてるの？レベルが違うでしょ。
ターミナルでのナビや検索を改善したり、結果にコマンドを実行するのが一番効率的だったよ。考えたことすぐできるようになった。
シェル自慢してる奴らばっかの中で、まともな意見見れてよかったわ。
プログラマーがコード書くより人と話す方が多いなら、それはソフトウェア自体を最適化してないってこと。今の世の中は実力じゃなく別の基準で評価されがちだけど、俺は毎日最高の自分を目指してるよ。実力主義はまた来ると思う。
プロの世界は絶対競争でしょ。でも環境設定を過剰に評価するエンジニアが多いのには同意だわ。
エンタープライズの仕事じゃ、ソフトウェア工場みたいで創造性なんてほぼないよ。社交スキルが命で、予算内で動くもの作るのが全て。職人技は小さい会社とかFAANGでやるもんだね。
プログラマーってのは、開発環境の設定方法を知ってることも絶対そうだろ。
プログラマーは環境設定じゃないって言ってるけど違うよ。ツール作りが本質なら、設定や機能拡張もツール作りと同じでしょ？どっちもプログラマーの仕事じゃん。優劣なんてないだろ？
そんなことは言ってないよ。コメントを誤解してたみたい。たぶん、読んでる時のイメージが違ったんだね。
基本ツールに慣れてるのは超大事。GNUのfindとかawkとか、昔から変わらずめっちゃ役立つし、自分もLinuxに移行して本当に良かった。VSCodeとか既成のツールしか使わない奴は、自分でハンデ背負ってるようなもんだよ。”shell bro”って言われたけど、マジな相手に挑んだらコテンパンにされるだけだろ。
昔のウィンドウマネージャー設定とかPerlの開発経験は、今使ってないけどスキルは残ったよ。その過程を楽しんだなら、費やした時間はムダじゃなかったんだ。
vimとかtmux使う人ってさ、Emacsの機能の半分くらいを、非公式でバグだらけだけど多分速い実装で自分で作り直してるようなもんだよね。
vim/tmuxもEmacsも両方使うけどさ、私のEmacs設定の方がvim+tmux設定よりよっぽど場当たり的で非公式、バグだらけだよ ;)
「半分」ってとこ見落としてない？Elispのコード量はマジで多いし、Emacsには専門アプリにすらない機能（月や太陽カレンダーとか！）もあるんだぜ。機能が少ないvim+tmuxがシンプルに感じるのは当たり前だよ。
知ってるよ！何年もEmacsをプロで使ってたし、今もEmacsじゃなきゃダメなこともある。でもね、シンプルで小さいものを組み合わせるのも良いんだ。
vim+tmuxは設定を何年も触ってないし安定してる。機能は少ないけど、Emacsで同じ機能を実現しようとしても色々苦労したんだ。
特に困ったのは、tmuxの＜c-b z＞みたいな機能、Evil modeのバグや統合の難しさ、Emacs内のターミナルの挙動やパフォーマンス、プロセス管理の面倒さ。
tmux+vimはEmacsのほんの少ししか実装してないけど、それが良いこともあるんだよ。俺はどっちも好きで使い分けてるよ。
は？tmuxの＜c-b z＞って何言ってんの？Emacsには少なくとも1987年から(delete-other-windows)コマンドがあるぞ。ズームトグルがないって文句言ってるのはわかるけど。
てかさ、自転車とBugatti Veyron比べてるって気づいてる？tmuxはシンプルなペイングリッドだけど、Emacsのウィンドウはもっと状態を持ってるんだ。
Evil modeがダメ？俺は生粋のvimmerだけど笑えるね。vim/neovim以外でEvil modeだけが唯一のACTUALなvimエミュレーションだ。他の全部ダメダメ。EmacsではEvil modeは拡張って感じじゃなくて、最初から組み込まれてる主要機能みたいなんだよ。
結局、機能少ないものが安定してるって言うのは当たり前だろ。全然違うものを比べるのは無意味だよ。
もっとコメントを表示（2）
その返信めっちゃ高圧的だね。(delete-other-windows)は存在するけど、俺が話してるズームトグルとは全然違うよ。
「文句言ってるだけ」って言うけど、ちゃんと具体例出したし！HNのフォーマットで見にくかったかもだけど。
自転車とBugatti Veyronの比較？うんうん、それこそが俺が言ってることで、Emacsは維持が大変なんだよ。俺は両方好きで使い分けてるって何度も言ってるでしょ。
自転車と車の例えもズレてるよ。俺は両方持ってるし、今回だって両方使ってる経験を話してるだけなのにさ。（gasp！）
Emacsに足りないのは、OSみたいに他のアプリと張り合えるブラウザのcanvasみたいな2D描画APIくらいだね。
Emacsに本格的なグラフィックエンジンが入るのは良い考えだけど、個人的にはEmacs内にブラウザがなくても困ってないよ。
ブラウジング履歴を辿ったり（¹ https://github.com/agzam/browser-hist.el）、Emacsからブラウザを操作したりできるんだ。
HNやRedditはOrg-modeで見てるし、最近HNを検索するパッケージも作ったよ（² https://news.ycombinator.com/item?id=44264368）。
エディタとブラウザを常に行ったり来たりする必要はそんなにないんだ。
vim+tmuxってさ、システム本来の機能、つまりパイプとかファイル、シグナルとかスクロールバックに依存してるんだよね。だから、ツールが環境を選ばずに透明に動くんだ。
これが移植性とかデバッグですごく強みになるの、特にssh越しとか制約されたシェルだとね。
こういうワークフローに慣れると、自分のvim configを作るのが自然な流れになるよ。
ssh越しって話だけどEmacsにはTRAMPモードがあるんだよ
「Transparent Remote file Access Multiple Protocol」の略でね
これを使うとローカルみたいにファイル編集できるんだ
/ssh:user@host:/path/to/fileみたいにね
踏み台経由で接続したり/ssh:jumphost|ssh:target:/fileとか
DockerコンテナやKubernetes Podsの中身も/docker:container:/etc/config
/kubectl:pod:/app/settingsみたいにアクセスできるしSudoもシームレス/sudo::/etc/hostsとかね
もちろん組み合わせもOK/ssh:server|docker:container|sudo::/etc/nginx/nginx.conf
何が良いかって言うと透明な連携DiredとかMagitがそのまま使えるんだ
環境切り替えなしで自分のEmacs環境に居続けられるよ
キーバインディングやパッケージカスタマイズもそのまま
SSH FTP SMB ADB Androidとかマルチプロトコル対応だよ
うんTRAMP経由のMagitね遅いけど一応動くんだ
https://news.ycombinator.com/item?id=44356346
まあTRAMPのせいじゃないんだけどさ
macOSのリモートだと上手く動かないことも多いんだよね
これもTRAMPだけじゃなくてデフォルト設定とか~/.zshrcと~/.zprofileの違いとか/etc/sshd/configの設定とか習慣の問題だと思うまだ完全には把握できてないけどね
こういう「全画面ターミナル画面共有」みたいなやり方の方が予測しやすいんだ
だって転送されるデータ量は通常キーストロークごとに1画面分ぐらいの文字と色だけだからね
それがメリットでもありデメリットでもあるんだ
ネットワーク接続に依存した入力遅延が発生するし出力も同じデータが何度も再送信されて再描画されることが多いんだよね
shellとかeshellについてもちゃんと触れるべきだったね
ansi-termは標準だとTRAMP経由では動かないけどワークアラウンドはあるみたいだよ
https://github.com/cuspymd/tramp-term.el
まだ試してないけどね
俺も小さなターミナルエミュレーター書いたことあるよ
2キーのtmuxプレフィックスをあらゆるコマンドでシングルキーCtrlに改造するためにね
他のターミナルエミュレーターでは通常無理なコマンドも対象だよ
https://github.com/ouillie/terminalle
Jynさんこんにちは
「Nixを使わないのは友達のNixユーザーが元々変なバグ抱えてるのにさらに変なバグ抱えてるからってのとランタイムでインストールできない哲学が気に入らないから」って言ってたね
最初の理由はまあそう
Nixはreadonlyなストア(/nix/store)にインストールするから普通の動的リンクされたバイナリは動かないんだ
パッケージングのアプローチが違うから何か壊れた時に回避が難しいことはある
でも1年以上NixOS使ってるけどメリットの方がデメリットより断然良いと感じてるよ
バグに遭遇することもめったにないしましてや致命的なのはね
腹立つのはソースコードなしで配布されるツールが多いことでそれにはpatchelf当てたりnix-ldみたいなの使う必要がある
後半のランタイムでインストールできないってやつはNixを使えば考え方が変わると思うよ
もちろんnix-env -iA $pkgってやることもできるけど推奨されてないんだ
ほらRustみたいなのもグローバルレベルでインストールしないようになったよnix-shell -p $pkgってやれば一時的なシェルで使えるしプロジェクトのflake.nixに直接依存関係を記述することもできるんだ
もしよく使うプログラムなら頑張ってNixOSの設定に追加するかな
あー誤解してたみたい
「ランタイムで」は「グローバルに」と同じじゃないんだ
ランタイムでローカルにインストールしたいんだよ
でもNixのエバリュエーターはNix derivationでパッケージングされてないものは管理できないし
ネット上の適当なツールを動かすためだけにパッケージング方法を調べたくないんだ
ああそれはもう少し複雑だね
選択肢としてはa) pkgs.autoPatchelfHookを使う[0] b) Nixを少し学んで自分でderivationを書く c) nix-ldを使う[1]って感じかな
pkgs.steam-runってのもあってゲームで想定される典型的な環境を提供してくれるよ
かなりのものが既にパッケージ化されてるけど大抵のものはパッケージ化するのがかなり早いと思うんだ
derivation[2]を1つか2つ書けばそんなに難しくないよ
他のディストリビューション向けにパッケージ作ったことないけどどれもかなり面倒そうだったんだよね
でもnixpkgs reference[3]にほとんどのものが載ってるしnixpkgsの似たようなパッケージのソースコードを見ることもできるよ
学ぶのには時間がかかるから魅力的じゃないのは理解できるけどね
[0]: https://github.com/svanderburg/nix-patchtools
[1]: https://blog.thalheim.io/2022/12/31/nix-ld-a-clean-solution-…
[2]: https://ayats.org/blog/nix-tuto-2
[3]: https://nixos.org/manual/nixpkgs/stable/
俺はNixを「ランタイムでインストールできない」からこそ使ってるんだよ
そうすることでランタイム環境が勝手に変わるってサプライズに遭遇しなくて済むんだ
コンテナでも部分的にこの問題は解決できるけどそれ自体にも使い勝手の問題があるしね
最近はどんなプロジェクトもnix flake init --template templates#utils-genericから始めてプロジェクト関連のものは全部そこに入れてるんだ
スクリプトでsshを使ったプロジェクトではmacOSとLinuxのデフォルトバージョンで受け付けるフラグが違ったからsshをピン留めしたパッケージとして入れなきゃいけないこともあったよ
どのマシンでもnix run nixpkgs#nmapって実行すれば心配なくプログラムを即座に実行できるのも大好きだよ
この機能はうちのプロジェクトの一部でも使ってて管理webインターフェースのリンクをクリックするとiTerm2[0]の「コマンドURL」みたいになってるんだnix run gitlab.com/example/example/v1.0 -- test http://example.com
これはターミナルで特定のバージョンのコマンドを実行するかプロンプトが出るんだけどソースリポジトリをチェックアウトする必要もないんだ
この場合はデバッグ目的で特定タスクをローカルで再実行するためだよ
[0] https://iterm2.com/documentation-command-selection.html
俺も似たような技使ってるよ！tmuxのスクロールバック機能とfzfをパイプで繋げて、tmuxの画面にあるものなら何でもzshで簡単に補完できるようにしてるんだ。これマジで便利だよ。
詳細はこちらのGistとThreadsの投稿を見てね。
https://www.threads.com/@kunalb_/post/C6ZQIOVpwMd
https://gist.github.com/kunalb/abfe5757e89ffba1cf3959c9543d9…
俺はXTermのデフォルト機能 dabbrev-expand を Alt-/ で使って同じことやってたんだ（設定はここ）。https://github.com/ttsiodras/dotfiles/blob/master/.Xresource…
これはどのShellでも動くんだよ。
でも、君の方法に興味あったから、Claudeに頼んでbash版に変換してもらったよ。https://claude.ai/public/artifacts/01a49347-1617-4afe-8476-0…
これがバッチリ動いてね、空いてた Ctrl-k に割り当てたら XTerm に依存しなくて済むようになった！
ありがとう！
こういうワークフローの共有方法、マジで感謝してるわ。読者によく合ってる。
動画に音があったらもっと良かったけど、後でアクションリストを読むのもアリだね。自分のやり方に取り入れたいこととか、考え方を変えたいこととか、いくつか学べたよ。
tmuxの難しいショートカットって言ってたけど、君や他の人は byobu って使ったことある？あれtmuxのラッパーだと思うんだけど、Fキー中心だから使いやすいと思うんだ。俺は10年くらい前に教えてもらってからずっと使ってるよ。
楽しんでもらえて嬉しいよ :) 記事は分かりやすくて、さっと読めるようにしたかったんだ。
＞tmuxの難しいショートカット
あー、俺はtmuxのショートカットほとんど全部変えてるんだ。ctrl-kはデフォルトのPrefixじゃないし、hも左のPaneを選択するデフォルトキーじゃないんだよ。
byobuは試してないけど、Readmeを軽く見た感じだと、デフォルトのキーバインドが良い以外は大差なさそうだし、ターミナルにこれ以上レイヤー増やしたくないかな。
あー、なるほどね！俺が byobu を推す主な理由は、初心者やデフォルト設定で使いやすいことなんだ。俺自身はカスタマイズしたことないし、Hotkeysも全部は覚えてないんだ。
俺たちの開発環境には byobu がインストールされてる Robot があって、非SWエンジニア（ハードウェア担当者とか技術者、QA）に使い方を教えるのがずっと楽なんだ（主にリモートセッションを維持するためにね）。
（だから俺も最近はあまり重いカスタマイズはしないんだ。ローカルと Robot のマシンで設定を統一したいからね…）
＞馬〜
ただ、ターミナルを本当に使いこなせる人を見たことあるなら、他のGUIベースのワークフローと比べて彼がどれだけ何倍も速く作業できるかに驚くだろうね。
これはAIで変わるかもしれないけど、今のところ俺はあまり期待してないな。
ポイントはグラフィックの欠如じゃなくて、キーボードとテキストがユニバーサルなデータ形式として使えることなんだよ。
GUIのプログラムは見た目はいいけど、相互運用性については悪夢だね。
とは言え、Emacsユーザーとしては、Emacsを使わないでこれほど努力する人がいることに驚きだよ。これはまさに Emacs が作られた理由だし、ハッカーが使いやすいように全部組み込まれてるのに。
