portal shit!

久々に開発環境をいじってて brew upgrade tmux したら色々ぶっ壊れてつらい。

具体的には以下のブログを参考に、 pane の swap を screen 風にしていた設定が効かなくなってしまった。

tmuxのペイン切り替えをscreenみたくする(ターミナルマルチプレクサ Advent Calendar 2011 23日目) - kozo2のはてなダイアリー

ターミナルマルチプレクサ Advent Calendar 2011の23日目でございやす。 すいやせん、日またぎ遅刻しやした。tmuxはscreenと比べると設定をあまりせずとも便利に使えるのがいいところですが、screenから乗り換えた際にどうしても不便に感じるのがactiveなwindowのpaneに別windowのpaneの情報をもってくることではないでしょうか。僕は下記のscreenでできてたことをtmuxでしたかったけどやり方わからず不満だったんですね。 windowをpane2個になるように分割してから 1.のpane2個のうち片側のpaneをC-n, or C-p で次or前のw…

kozo2.hatenadiary.org

## paneの入れ替えをscreenっぽく
bind-key C-n swap-window -t:+ \; swap-pane -s:-
bind-key C-p swap-window -t:- \; swap-pane -s:+

こういう使い方をしていた。

# 状態 1
window 1 A|[B] <- window 1 の pane B がアクティブ
window 2 C     <- window 2 に pane C が単独で存在

C-b C-n を入力し、以下のような配置になっていた（これまで）。

# 状態 2 (tmux 2.8)
window 1 A|[C] <- window 1 の pane B があったところが pane C になる
window 2 B     <- window 2 には pane B が単独で存在

ところが tmux 2.9a 以降ではこんな風になってしまう。

# 状態 2 (tmux 2.9a)
window 1 [B]   <- window 1 pane B が単独で存在しアクティブ
window 2 A|C   <- window 2 に pane A と C 単独で存在

このほかにも tmux-powerline が綺麗に動かなくなったりして色々厳しい。 tmux は 2.8 までが安定している気がする。

仕事ではほとんどコード書かなくなってしまったのでたまの休みで時間があるときになんかやろうとするとこういうトラブルに遭遇して死んでしまう。プログラミングスキルのみならず開発環境の維持・セットアップにいたるまで、プログラミングに関連するあれこれは料理人が日々包丁の手入れをするように常日頃から磨いていないとさび付いてしまう。

追記

tmux の件は以下なんかを参考にしてみようかな。

tmux-change-paneというコマンドを作った - おおたの物置

tmux-change-paneというコマンドを作りました。 https://github.com/ota42y/tmux-change-pane tmuxで現在開いているウィンドウの一覧を表示し、peco(pecol)で絞り

ota42y.com

さらに追記（2019-08-25T11:34:25）

.tmux.conf を以下のようにしたら解決した。

bind-key C-n swap-pane -t:-
bind-key C-p swap-pane -t:+

むしろ最近の変更で tmux の pane スワップの挙動が自分の好み（ screen 風）に近づいたみたい😅

vim + tmuxでVSCodeっぽい開発環境を作る

vim + tmuxでVSCodeっぽい開発環境を作る MicrosoftのVisual Studio Code(以下VSCode)には期待していて何度かエディタの乗り換えにトライしてるんだけど、今回もあえなく失敗してしまった。でもその度に改善アイデアを得ては自分の環境に取り入れている。定期的に色んなエディタを試して良いとこ取りをするのは、結構いいかもしれない。 自分は基本的にvimとtmuxを併用してターミナルで作業をしている。本稿ではVSCodeの特徴を軸に自分のvimとtmuxの設定をシェアしたい。説明はtmuxとvimの基本を知っていることを前提とする。以下概要： * VSCodeっぽい画面分割 * VSCodeっぽいファイラ * VSCodeっぽいエラー表示 * (VSCodeっぽくない) プロジェクトごとにtmuxタブを開く VSCodeでは画面下にターミナルを表示できるのが便利だと思ったので真似した。tmuxで上下7:3で分割している。上段でvimを起動して、下段でコンパイルなどをする。下段は更に３つに垂直分割する事が多い。この画面分割をコマンド一発で出来

blog.craftz.dog

↑の記事を読んで tmux でウィンドウを上下分割して、上でコード書いて下でテスト実行したりするの便利そうだなと思ってまねしてみてる。とてもよい。

ただ分割比を調整するために毎回何度かキー入力が発生するのがいまいちだなと思っていた。 tmux のセッションを開始するときにしかこのコマンドを実行することがないので面倒だなと思いながら都度手動で調整していた。

しかし tmux には select-layout という機能があって、 Control
+b + Alt+1 とか入力するといい感じに pane を配置し直してくれることを思い出した。上下分割は C-b + M-3 に main-horizontal というスタイルが割り当てられており、上の pane をメインにして上下分割してくれる。このとき main-pane-height という設定項目に任意の値を設定しておくと分割した pane の高さを指定できるようだった。デフォルトだとメインの pane の高さは小さめなので自分は set-window-option -g main-pane-height 60 にしておいた。これで tmux を起動してウィンドウを水平分割したあと C-b + M-3 とやるだけで 8:2 くらいで二つの pane に水平分割されるようになった。ちなみに左右で分割したときの値を調整したい場合は set-window-option -g main-pane-width 230 などとしておけばよい。便利。

fish-shell に移行 してこれで .zshrc のお守り業から解放されたと思ってたが、最近異常にシェルの新規セッションの開始が遅くて死にそうになってた。特にやばいのが git mergetool したときで、これは内部的には沢山の fish のプロセスが起動して diff を調べて最終的に vimdiff で表示しているように見えた（僕は git config editor=vim です）。下手するとちょっとしたコンフリクトを修正するために vimdiff が起動するまで 15 分くらい待たないといけないことがあって、 20 年くらい前の Photoshop 作業の現場[^{1]みたいな感じになってた。これはかなりやばくて、生産性ががた落ちになる。} vimdiff が開くまでに待っている間に他のことやり始めて、気がつくと平気で夕方になってたりする。

fish-shell のバージョンを 2.7.0 に上げたことが原因かと思って、かつて快適に使えていた fish のバージョンに下げたりしてみたが解決しなかったが、以下の記事にたどり着いて $fish_user_paths への値の push をやめたところ解決した。

fish shellの起動が遅くなった時の解決方法 - Qiita

TL;DR fish shellの起動に3〜4秒ぐらいかかるようになった。 config.fishの$fish_user_pathsの設定方法に問題があった。 この問題の原因と解決方法をまとめた。 何が起きたか fish shellを起動してコマンドが入力できる...

qiita.com

fish-shell での PATH の通し方として以下のようなのがよく出てくる。 Homebrew で keg only なやつを入れたときにも表示される。

set -U fish_user_paths $HOME/Library/Python/2.7/bin $fish_user_paths

しかしこれをやると $fish_user_paths にどんどんパスが積まれていってしまう。どうもこれが原因で遅くなるようだった。自分の環境でも echo $fish_user_paths してみたところかなり酷いことになっていた…。

↑の Qiita 記事では set -U fish_user_paths するときに第三引数を消せとあったが、それでは根本的な問題の解決にならない（ Python やら Ruby やらいろんなものの実行ファイルを PATH に通したいはず）。自分は以下の方法で解決した。

set -x PATH /usr/local/bin $PATH

bash や zsh で export PATH=/usr/local/bin:$PATH とやるのと同じオーソドックスなやり方だと思う。

これだけではこれまでに散々肥えた $fish_user_paths は残ったままなので適当に set -U fish_user_paths '' とかやってあげると空になって起動が速くなる。

fish-shell の set -U はセッションをまたいでグローバルかつ永続的に設定される変数定義の方法っぽいので下手するとその環境で fish を使い始めてからずーっと残ってしまう可能性がある（端末を再起動したらリセットされるかも知れないけど）。

まとめ

• set -U は基本的にしない
• $fish_user_paths は設定ファイルの中では使わない
• PATH を通したいときは set -x PATH を使う

[^1]: 何らかの処理を実行して処理が完了されるまでにめっちゃ時間がかかるのでその間にたばこを吸いに行くことが可能だったらしい

追記 2020-05-23

set -x PATH /usr/local/bin $PATH がよいと書いていたが、 tmux を起動すると $PATH に重複してパスが登録されてしまう。ファイナルアンサーとしては以下。

$ set -g fish_user_paths /usr/local/bin $fish_user_paths

• set -U は使わないではなく set -g する
• $fish_user_paths は設定ファイルの中でも使ってオッケー
  • パスを通したいときは set -g fish_user_paths /usr/local/bin $fish_user_paths とやる
    set -x PATH /usr/loca/bin $PATH をやると tmux のセッションの中でパスがダブるため