比較的大きな規模のプロジェクトになると、ディレクトリツリーの階層もそれなりに深くなる場合が多い。しかも同じディレクトリに常にとどまって作業をしていればいいという話にならなくなってくる。ディレクトリを移動する度に cd /path/to/foo とか cd /another/path/fuga とかもう打ってられないことに気がついた。
vim とかのエディタ内のファイルマネージャーを使えばいいじゃない、と一時期は考えて netrw とか nerdtree とかを我慢して使っていた時期もあったが、どうもディレクトリの移動の度にリターンキーを「ッターン!」 しなければいけないのがつらく、結局使わなくなった。
ある日、コンソール上で画像ファイルをプレビューしたくなった。そんなソフトはないかと捜していたら、ranger にいきついた。いざ使ってみると、ファイルやディレクトリの移動、そしてファイルを開く操作が全て hjkl だけで済むのが異常に心地よいことに気がついた。w3m を入れて設定に一行足せば、以下のように画像ファイルのプレビューも出来る。cd /path/to/foo/bar するよりはかなり速い。 また、ranger を開きながら Shift+s でシェルに落ちることもできる。これもかなり楽。
また、vim の場合だと、ファイルを開きながら、別のファイルを選んで開くときも、 netrw とかを使わずに ranger を使えるモードがあることに気がついた。こんな設定 を ~/.vimrc に書けば、<leader>r を押すことで ranger でファイルを選ぶことができる。
そんな感じで喜んで使っていたのだが、Pythonのファイルを扱っていると若干問題があった。types.py というファイルがディレクトリに存在すると、それを vim から ranger で開こうとした時点でエラーになってしまうのだ。
1 2 3 4 5 6 7 8 9 10 11 12 |
|
これは ranger 自体が Python で書かれていることと、Pythonインタプリタ自体の問題 が重なったことによって起こることだった。けれども、今の職場で主に使われているのは Python なので、どうにかして解消しなければ ranger は使えないという話になってしまう。
仕方なく、細かすぎて伝わらないpatch を書いた... vim ファイルだけではなくて、コアのイベントアクションにまで手を加えているので、全く受け入れられる気がしない... それに vim 連携のためだけに types.py を特別扱いするとかアフォかと。俺がメンテナなら多分 Reject するだろうなと思いつつ、fork したコードだけは置いておくのであった(´ー`; )