反省はしても後悔はしない

Vim とか備忘録とか。それと関数型言語勉強中

poetry を使った jax 0.4.1 のインストール

poetry を使って jax をインストールしようとしてハマったのでメモ。

結論

以下のような pyproject.toml を書いて poetry install。

poetry==1.3.1, poetry-core==1.4.0 で動作を確認。

[[tool.poetry.source]]
name = "jax"
url = "https://storage.googleapis.com/jax-releases/jax_releases.html"
default = false
secondary = false

[[tool.poetry.source]]
name = "jax_cuda"
url = "https://storage.googleapis.com/jax-releases/jax_cuda_releases.html"
default = false
secondary = false

[tool.poetry.dependencies]
python = "^3.8.2"
jaxlib = {version = "0.4.1", source = "jax_cuda"}
jax = {version = "0.4.1", source = "jax"}

これで jaxlib==0.4.1+cuda11.cudnn86 と jax==0.4.1 が入る。cuda と cudnn のバージョンのところは環境依存かもしれない。 cuda 用の source とそうでない source を2つ書くのがポイント。 ただし、公式のインストール手順 https://github.com/google/jax#pip-installation-gpu-cuda には後者の URL は記載されておらず今後動かなくなる恐れがあるかもしれない。

cuda 用の jaxlib は Google が提供している URL から持ってくる必要があるが jax の方は PyPI にあるやつで動くはずなのだがなぜか poetry add jax だけだと

  Unable to find installation candidates for jax (0.4.1)

と言われてしまいインストールできなかった。

lexima.vim をアップデートしました

ここ数年いろいろあって*1あまり活動できてなかったのですが、最近やっぱりこのままじゃまずいなと思い始めて仕事に関係ないプログラミングの時間を積極的に作っています。

その中で拙作の Vim プラグインである lexima.vim (https://github.com/cohama/lexima.vim) にいくつか機能追加をしました。

lexima.vim は対応する括弧 () [] {} "" '' や括弧以外のいろいろ def ~ end など を自動入力するためのプラグインです。似たようなプラグインはたくさんある (e.g. auto-pairs, delimitMate) のですが、こいつは . キーによるリピート (ドットリピート) が常に可能という点で他と異なります。(他にも柔軟な設定とかが可能というのもあります)

今回一応バージョンとしては v2.0 ということで内部的には大きな変更を実施したので変更点とかを紹介したいと思います。

アンドゥが途切れにくくなった

lexima.vim は括弧の対応等を補完しつつ、常にドットリピート可能なように作られています。当時はカーソルを動かすだけでアンドゥ履歴が途切れたりしていたのを setline() 関数呼び出しを使った黒魔術で気合でドットリピートできるような実装になっていました。しかし、これによってアンドゥが括弧等を入力するたびに途切れてしまい、1つの入力をやり直すのに何回も u を押下しなければならずストレスフルでした。

新バージョンではこれを改善して、少なくとも改行を入力するまではアンドゥが途切れないようになります。実装としては改行するまでは対応する括弧を補完するのに ()<C-g>U<Left> などを使っているというだけです。何のことかわからない方は Vim のヘルプを参照ください。(:help i_CTRL-G_U) 改行を入力するたびにアンドゥが途切れてしまう問題は依然として残っています。これについては今のところ改善の方法がないのでどうしようもないです。

アンドゥがについては前述のとおりなのですが lexima.vim はドットリピート対応したいがために作ったプラグインなのでもちろん複数行入力だろうが1行だろうが (そのようにルールを設定する限り) ドットリピート可能である点に変更はありません。

この変更、だいぶ内部の処理に手を入れており既存のルールが壊れてしまわないか不安もありました。そこで開発版としてまずリリースし、人柱デバッグvim-jp の Slack にいる方たちに手伝ってもらいました。結果的には特に大きな問題はなさそうだったのでそのままリリースすることが出来ました。

vim-jp Slack でデバッグに協力してくれた皆様にこの場で感謝の意を表明します。どうもありがとうございました。

leavedeleteinput/input_after を同時に指定できるようになった

分かる人には分かる変更です。表題のとおりなんですがそもそも leave/delete ってなんだ?という方もいるかもしれません。そういえばブログとかで紹介したことがなかったのでここで軽く触れておきたいと思います。

leave について

(|) というときに ) を入力すると ()| のように実際に閉じ括弧を入力するのではなく単に入力済みの閉じ括弧を抜ける機能です。 lexima.vim のデフォルトルールで以下のように定義されています。

call lexima#add_rule({'char': ')', 'at': '\%#)', 'leave': 1})

上のルールの読み方はカーソル (\%#) の右側に ) があるときに ) を入力すると1文字だけ右に移動する、となります。「右に抜けるのになんでわざわざ leave なんてあるんだ、<Right> でよくない?」みたいに思われるかもしれませんがこれはドットリピートのためです。<Right> はドットリピートを途切れさせてしまいます。lexima.vim が出来た後に <C-g>U の機能が Vim に追加されたので今となっては <C-g>U<Right> とほとんど同じですが、一応 leave だと複数行入力したときでもうまくドットリピートさせるための処理の兼ね合いで leave でないとだめなケースがあります。

ただし、leave で移動できるのはこの挿入モード内で lexima.vim が自動入力したものに限ります。このあたりは好みが分かれる部分かもしれませんが少なくともデフォルトルールでは基本的には常にドットリピート可能なルールのみ設定されています。複数行入力でのドットリピートを諦める代わりに常に移動したいのであれば以下のようにユーザ側で定義することも出来ます。

call lexima#add_rule({'char': ')', 'at': '\%#)', 'input': '<C-g>U<Right>'})

あと、leave は改行やインデントも含めて抜けられるので以下のように設定すると

call lexima#add_rule({'char': '}', 'at': '\%#$\n\s*}', 'leave': '}'})

下みたいなときに改行された後の } の右までジャンプできたりします。ちなみに leave には数字だと文字数分だけ移動、文字列だと指定した文字が最初に見つかるまで移動します。(いずれも lexima.vim が自動入力したものに限ります) これはデフォルトにはないので気に入ったら設定してみてください。もちろんこれもドットリピート可能です。

void foo() {
  |
}

詳細は本体のドキュメントの方を参照してください。:help lexima-rules-leave

delete について

delete<Del> の入力に相当するものです。leave は自動入力された閉じ括弧などを抜けるためのものですが、こちらは抜ける代わりにその文字列を削除します。ただし、今となっては delete はほとんどの場合 <Del> と同じです*2<Del><Del>... と書くよりも "delete": 10 と書くほうが簡単みたいな使い方になります。

あと、後述するように input_after と同時に指定した際の削除の順番に一応関係します。

改めて、leave/deleteinput/input_after を同時に指定できるようになったことについて

ここまで leavedelete の紹介をしましたが、以前までのバージョンでは leavedeleteinput はいずれか1つしか指定できませんでした。と言ってもこれは実は単に実装上のミスというか考慮漏れで特にドキュメント等にも同時に使えないというのは書いていなかったのですが。。。今回改めてちゃんと仕様として定めて正しく動くように実装しました。

これでカーソルを移動しつつ追加で文字を入力するのようなことが可能になります。

これがどういう場合で嬉しいかというと例えば以下のルールを追加すると

call lexima#add_rule({
  \ 'char': '<CR>',
  \ 'at': '{ \%# }',
  \ 'delete': 1,
  \ 'input': '<BS><CR>',
  \ 'input_after': '<CR>'
  \ })

hoge { | } の状態で <CR> を押下すると前後のスペースを削除しつつ以下のように改行してくれます。

hoge {
  |
}

入力は input_after -> delete -> leave -> input の順で処理されます。なのでこの場合 input<Del><BS><CR> としても既に input_after によって改行が入力された後なので <Del> で削除されるのはスペースではなく改行になってしまいます。

もう1つ例を紹介します。

call lexima#add_rule({
  \ 'char': '>',
  \ 'at': '([a-zA-Z, ]*\%#)',
  \ 'leave': ')',
  \ 'input': ' => {',
  \ 'input_after': '}'
  \ })

これを設定すると typescript などの匿名関数を簡単に入力するためのスニペットのようなことができます。(foo|) のときに > を押下することで (foo) => {|} に展開されます。 こちらは 無人島に持っていく(Neo)vimプラグイン10選 (TS開発環境編) の記事で紹介されていたものをドットリピート対応にしたものです。

このように leavedeleteinput input_after を同時に指定することで以前はドットリピート対応にするのが難しかったルールも書けるようになりました。

\1 などの部分マッチを入力に使えるようになった

HTML の閉じタグを自動で入力させる場合、つまり <div|>> を押下すると <div></div> のようのしたいときはどうすると良いでしょう。 以前のバージョンではこれはかなり困難でした。閉じタグにもタグ名を書く必要がありますが、前方で入力したタグ名を input_after 等で利用する方法がなかったからです。

これを解決するために with_submatch というキーを新たに設けました。以下のようなルールを設定すると先程の閉じタグの補完ができるようになります。 もちろんドットリピート可能です。

call lexima#add_rule({
  \ 'char': '>',
  \ 'at': '<\(\w\+\)\%#>',
  \ 'leave': '>',
  \ 'input_after': '</\1>',
  \ 'with_submatch': 1
  \ })

ポイントは at\(\) を使って部分マッチを指定し、それを input_after では \1 で指定できることです。

他にも例えば tex\begin{foo}\end{foo} の対応を自動で入力させる場合などにも使えます。

この機能の注意点として、まず inputinput_after に指定した文字列は置換用の文字列として扱われるので通常の場合とは差異があります。具体的には \\\ にする必要があるなどです。詳しくは :help sub-replace-special を参照してください。 あとは、追加したばかりの機能なのでまだバグがあるかもしれません。with_submatch を指定しない限りは使われない機能なので既存のユーザには影響ありませんが、もし利用したい場合はデバッグのつもりで使ってもらえるといいかもしれません。

この機能、頑張れば HTML のタグを閉じる系のプラグイン (e..g https://github.com/alvan/vim-closetag) を代替、しかもドットリピート可能にできます。とはいえ単純なものなら上にあるルールでできるんですが、<br> は閉じタグを入れない、とか <div class="hoge"> みたいな例外を考え出すと結構面倒くさいので標準で入るのはまだ先になりそうです。(誰かが PR くれれば取り込みたい...)

なお、この機能は Pull Request で頂いた機能を少し修正して取り込んだものになります。感謝。

おわりに

以上、lexima.vim の最新の機能追加の紹介でした。

今後の展望としては、内部構造のリファクタリングを引き続き進めていこうと思います。今回紹介しておいてなんですが正直 leave とかいう概念難しいんじゃないかと思っていて、このあたりを直感的に設定できるようにしたいみたいな思いがあります。(できるかどうかはともかく)

あと、at とか filetype とか syntax 等の発動条件まわりももう少し柔軟にしたいです。この手のプラグインだと対応する括弧の釣り合いが取れているかどうかで自動入力するしないを変えるものもあり、そのような設定が可能なようにする機構を考えています。

まぁでもそういう大工事はまとまった時間が取れたときにやって、とりあえず直近は溜まった Issue をひとつずつ片付けていこうかと思っています。 直近は nvim-treesitter で不具合が出る問題とかですかね。

バグ報告、機能追加要望等ありましたら遠慮なく GitHubIssue までよろしくお願いします。

*1:以前は仕事のストレスを趣味開発のエネルギーにしてた説。転職してから仕事上でのストレスがほぼなくなりました。

*2:確か昔は <Del> でドットリピート途切れていた気がするんですが気づいたら大丈夫になっていました

転職します

この度、6年とちょっと勤めた SIer を退職することになりました。7月から来栖川電算という会社で働きます。本日5/31が最終出社日でした。

転職に至った経緯とか

今の会社はいわゆる大手 SIer なのですが、その中で自分の今後のキャリアを考えられなくなったのと主とするビジネスのやり方に疑問を持ったというのが転職の主な理由です。

キャリア的な問題

6年目ともなると会社的にはプログラミングは卒業して人やお金の管理とか顧客との折衝のような仕事を期待されるようになってきました。自分としては技術的なところで何かしら活躍したいという気持ちが強く上司にもそのことで相談したりもしたのですが、結果的には自分の思いが叶えられるようなキャリアを提示されることはありませんでした。

ビジネス的な問題

業界の中では比較的大きい会社なので部署によってはもしかしたら状況が違うのかもしれませんが、少なくとも自分の周りでは単価の安い人を大量に雇って人海戦術で仕事を回すようなやり方が普通でした。いわゆる多重下請け構造の一端を担っていたわけです。また、そういう仕事のやり方ですので当然採用される技術もできない人に合わせる形になります。Git 等によるバージョン管理はなされず日付フォルダで管理、テストは自動化されることはなくエクセルスクショエビデンスをひたすら撮るだけ。このままでは業界全体が IT の進化に取り残され衰退していく未来しか見えませんでした。そういったあまり誇れないような仕事に対して常々疑問を感じながら仕事をしていくのは嫌だという気持ちもありました。

働き方の問題

この業界では客先常駐というケースは珍しくありません。自分も多分に漏れず客先常駐をしていました。常駐先では Vim 含むフリーソフト禁止、携帯のカメラ禁止などひたすらに厳格なルールを守らされ、そのことに対してかなりストレスを感じていました。また、仮に常駐が終わり自社に戻ったとしてもまたすぐに別の客先に常駐することにもなるかもしれないという不安がありました。

上記のようなことをぼんやり考えていた折にたまたま来栖川電算の山口さんとお話する機会があり、その後いろいろあって転職が決まりました。

今後とか

とりあえず6月は丸々有給消化です。1ヶ月も休みあるのすごい。雑に旅行したり実家の九州に帰ったりします。 あと、機械学習とかを勉強します。

fcitx の候補ウィンドウが出てこなくなったときの対処メモ

現象

Arch Linux のシステムアップデート (pacman -Syu) を実行したからかはよく分からないが、ある日突然 fcitx の挙動がおかしくなった。

具体的には入力モードを切り替えて日本語入力および漢字変換はできるのだが候補ウィンドウが出てこない。これは変換候補が複数ある場合に非常に不便。

結論

どうも Infinality-Bundle をインストールしていると依存しているパッケージの一つが正しく動かなくなるようだ。 そのパッケージというのは fcitx が依存している pango がさらに依存している harfbuzz。 このページに従って Infinality-Bundle をアンインストールすれば解決する。

VimConf 2014 に行ってきたよ

11/8 に mixi さんにて開催された VimConf2014 に発表者として参加してきました。

スライドなどは以下にまとめらています。

Reports - VimConf 2014

以下雑感など。

Identity of the Vim (@Kaoriya)

これはとても共感できる内容でした。 Vim の強みとは、というところでいろいろな機能が挙げられていたけど、やはり僕も vim-jp の存在が一番大きいのではと思います。 あと、Vim 使うならいろいろやろうというのも完全に同意でした。 「達人プログラマー」という本では「毎年少なくとも一つの言語を学習する」ことを勧めています。 どんどん新しい言語にチャレンジするのにいちいち開発環境の使い方まで覚えないとしたら非効率ですが、Vim さえ覚えていればその問題はなくなります。 せっかく Vim を使っているのだし、どんどん新しいことにチャレンジしていきたいですね。

PM2 (@ujihisa)

PM2 という vital モジュールに関する説明でした。 外部のプロセスと非同期、並行に通信するためのものらしいです。 PM1 との違いは主にプラグインから PM を呼ぶときのインターフェースなのかなという理解 (違ってたらすみません)。 ujihisa さんは新しい言語がでたとき、それに付随するツールをエディタ問わず利用できるようにしたい、という大きな野望を抱いているようでした。 とりあえず今ある REPL (e.g. Haskell の ghci とか) と連携するようなプラグインとかが簡単に書けそうで便利そうと思いました。

f (@Linda_pp)

f マッピングについて。 Vim 標準の f の説明と、 shot_f とか improvedft とか clever-f とかいろいろな f 拡張プラグインの紹介でした。 f 自体は僕はかなりの頻度で使うのですが、まだ拡張プラグインは入れてません。 紹介されたプラグインを試してみて自分の使用感に合いそうなものがあれば使ってみたいです。 あと、オチがとても秀逸でした。

Hey, Java! Vim is coming. (@kamichidu)

Eclipse の方がまだ便利と分かった上で、あえて Vim 上で Java を書く、という話でした。 僕が昔お仕事で Java を書いていた時は Eclipse + vrapper (Vim バインドを提供する Eclipse プラグイン) を使ってまぁある程度満足していたのですが、Vim が使えない不満も確かにありました。 これからに期待です。

auto closing parenthesis (@c0hama)

僕の発表でした。 他のエディタによくある閉じカッコとか閉じクォートとかを自動入力する方法についてです。

以下補足。 閉じカッコ自動入力というと完全に好みが分かれる挙動だと思っているので万人受けするようなものではないですが、 vim-smartinput やそれをもとにした lexima.vim はその域を超えたインサートモード (コマンドラインモード) 用のマッピング定義フレームワークなので、カッコ自動入力以外にもいろいろなことに応用できます。 あと構成上ドットで繰り返せるのは lexima.vim だけみたいに見えてしまったかもしれないですが、実は vim-autoclose というプラグインもあってそれはドットでの繰り返しに対応しています。まぁ機能と拡張性がアレだったし時間がなかったので紹介を省きました。

怖くないマクロ入門 (@deris)

Vim のマクロの基本的な使い方の話。 かなりわかりやすく、かつ実用的な例が紹介されていてとても良い内容だったと思います。 僕もマクロはよく使います。例えば、Agit.vim のテストコードを vspec から themis に乗り換えるときにはマクロを使って半自動的に変換しました。 確かにマクロは使うだけなら簡単なのですが、実用的でかつ変化に強いマクロを作るには多少の訓練が必要ですね。 完全に余談ですが、僕はマクロで記録中に「あ、間違えた」ということがよくあるのですが、そういうときは "xp" などで記録中のマクロをバッファに貼り付けて間違った部分をちょろっと修正して 0"xy$ でマクロの方に反映するというテクニックを使います。

Test for Vim script (@thinca)

Vim script のテスティングフレームワーク、themis の紹介でした。 themis はかなり初期の頃から使っていて、いくつかコントリビュートもしたので個人的にもかなり応援しているプラグインです。 テスティングフレームワークはかなり乱立してますが、themis はデファクトスタンダードになれるだけの可能性を秘めていると思っているのでみなさんも使いましょう。

Let's talk about neovim (@Shougo)

Vim からフォークした Neovim の話でした。 個人的には一番楽しみにしていた発表でした。実際の内容も Neovim の最近の動向や問題点がわかりやすく説明されており大変素晴らしかったです (歌含む)。 とは言え僕自身はあまり Neovim には期待をしていなくて、単純に別のエディタとして見たときに Neovim がどういう機能を持っているのかを知りたかったというのが本音です。

かなりすごい発表(かなり) (@momonga)

Vim から音を出すとどうなるかという内容でした。 スライドも発表の内容もとてもおもしろかったです。(かなり) 半分くらいネタなのかなと最初は思っていたんですが、実際に音で何かを通知するというのはなにかに使えそうだと思いました。

XVim with MacVim and smartgrep (@pebble8888)

XcodeVim っぽい操作を提供するもの、らしいです。 Mac 全く使ったことがないので XCode というのものもあまり深くは知らないのですが、Eclipse における Vrapper とか VisualStudio の VsVim とか IntelliJ IDEA の IdeaVim とかに相当するものと理解しました。 こういう系のソフトウェアはオリジナルの Vim の操作性にどれだけ近づけられるのかが重要だと思っているのですが、XVim はこのあたりかなり頑張ってる印象を受けました。 あとは MacVim と XVim の間を行き来するのは便利そうでした。

/-improved (@haya14buya)

/ による検索と incsearch.vim の紹介でした。 / はよく使うんですが、d/ みたいにモーションとして使ったり、//e みたいにオフセットを活用したり、といったことは僕は余りやらないのでよい復習になりました。 incsearch.vim は僕の中で最近かなりアツいプラグインです。既存の / の使用感はそのままに便利な機能が追加されているので非常に便利感あります。 ただし、僕の場合は / の検索中のマッピングを lexima.vim で定義しまくっているのでただ乗り替えるだけでもちょっと苦労しましたが...。 僕みたいな特殊な場合を除けば、入れるだけで競合もデメリットもほぼない感じになっているのでとりあえず1回は試してみるといいと思います。

vim script初心者に使ってもらいたい、転ばぬ先の杖「Vint」 (@Kuniwak)

pythonVim script の Lint を行う vint の紹介でした。 syngan さんの vim-vimlint は僕も試したことがあったのですが、あまりの遅さにあきらめてしまっていました。 vint は python で書かれているため高速に動作するようです。 かなりライフチェンジングっぽいので積極的に使っていきたいですね。 あと、vint のアイコンがめっちゃかっこよかったです。

Jenkins + vimenv で 最新のVimを使おう! (@raa0121)

北海道から来たらぁさんの発表でした。 vimenv が rbenv の rb を vim に置換してできているというは知りませんでした。 というかそんな簡単な感じでできるのすごい。 Jenkins で9分に1回最新を取ってきてビルド+テストまでしているそうです。 最新の〜というタイトルでしたが、どっちかというとある特定のバージョンで起きる Vim のバグの原因究明なんかに役に立ちそうだと思いました。 あの環境欲しいんですが、サーバが...。

休憩中 + 懇親会中など

そういえば、休憩中に ujihisa さんと VimScala を書くときの話をしました。 ujihisa さんは ScalaVim で書くそうですが特殊なプラグインとかは使ってないそう。 Haskell における ghc-mod とか OCaml における ocamlspot みたいなのが Scala にもあれば Vim から使えて便利そうなのですが。。。

懇親会では同じく名古屋から来た koara-local さんとは Nagoya.vim 第3回の話などをしました。会場問題とかプロジェクタ問題とかはあるんですが、とりあえず1月あたりには開催しようかなと思います。 dice_zu さんがタイミング合えば参加したいとおっしゃっていたので期待大です。

それと、basyura さん (だったはず) から「Agit.vim にファイルモード (あるファイルだけの git log を見るモード) が欲しい」という要望をいただきました。 はい実装します。

終了後

有志でカラオケに行きました。カラオケ大好きなのでとても楽しかったです。 カラオケ中に vimrc 読書会の時間になったので歌う合間に参加しました。 カラオケ後、宿がなかったのでももんがさん家に泊めてもらいました。ももんがさん神。ありがとうございました。

まとめ

というわけでとても楽しい一日(?)でした。来年も絶対参加したいです。

Nagoya.vim #2 を開催してきた

Nagoya.vim #2

9/20 (土) に Nagoya.vim の第2回を開催してきました。前回の第1回は2013/9/17だったので、約1年ぶりになります。どんだけさぼってたんだ...

第1回は僕と sgur さんで発表をするという会でしたが、第2回はもくもく会にしました。もくもく会形式だと人が集まらないんじゃないかと思いましたが、結局13人くらいの人が集まりました。(うち遠方からの参加者が5人!)

Pre Nagoya.vim

はるばる東京からやってきた thinca さん Linda_pp さん BOXP さんと11時半くらいに名古屋駅に集合して、名古屋めしを食べに行きました。 味噌カツ (thinca さんは名古屋コーチン親子丼) を食べながら、Vim script のラムダ式の話などをしました。

Nagoya.vim 開始!

移動時間を適当に見積もっていたため微妙に遅刻しましたが、早めに着いた人と協力して会場を設営しつつ予定開始時間にはなんとか間に合わせることができました。 さてイントロダクションをやろうかというところで、まさかのプロジェクタに接続できないトラブル (端子がなぜか自分の D-sub コネクタと合わない) に見舞われるという...。はやぶささんの PC には接続できたので、それをお借りして簡単なイントロダクションと各自の自己紹介をしました。 そういえば girigiribauer さんが vimrc 整理して近々公開したいみたいなことを言っていました。vimrc 読書会で読まれる日が楽しみですね。

thinca さんによるライブコーディング

Lingr でちょろっと話をしただけで、やるかやらないかも正式に決めていなかったんですけど thinca さんに頼んでライブコーディングをやって頂きました。お題は「行末スペース、全角スペースなどがコード中に含まれていた場合に、それをステータスラインでお知らせするプラグイン」。 thinca さんは「全然設計していなかった、もっと考えていればー」などとおっしゃっていましたが、それでも短時間でプラグインを作り上げてしまうあたりさすがだなぁと思いました。 惜しむらくは会場からの質問が少なかったこと。その辺りは主催者として何かしらできたのではというのが反省点ですね。

各自もくもく

あとはみんなでもくもくしていました。僕は今進めているプラグインの開発をやろうと思っていたのですが、ノートPCの方にコードを移動し忘れたので、Agit.vimリファクタリングなどをしました。

成果発表

sgur さんが vim-gitgutter の魔改造版を作っていました。clientserver を使って非同期処理を行うなど本家とは完全に別物になっているようです。 はやぶささんは incsearch.vim という Vimインクリメンタルサーチをもっと便利にするプラグインの開発状況を報告してくださいました。 とても便利そうだったので完成が待ち遠しいですね。 あとは vimrc 読書会や Vim プラグイン読書会の宣伝もありました。 なお、ぼくのしんちょくはありませんでした。

懇親会

Nagoya.vim #2 は会場の都合で終了時間が 16:30 だったのですが、たまたま katono123 さんが近くで 16 時からやっている居酒屋を見つけていたので終了後は有志でその居酒屋に移動して懇親会をやりました。 懇親会では koara-local さんがみんなの飲み物を頼んだり店員さんを読んだりなど幹事的仕事をしてくださいました。ありがとうございました。主催者とは何だったのか。 あと、Agit.vim の機能要望の話とか今作っているプラグインの話とか関数型言語の話などをしていました。 そして、この居酒屋なんと 19:00 までは飲み物が半額になるとのことで 17:00 から 20:00 まで飲み食いしていたにもかかわらず一人3000円いかないくらいで済んでしまいました。まさかこんな穴場があったとは。。。

おわりに

今回は企画段階から懇親会まで終始グダグダでした。すみません。。。 次回はもっとスムーズに会が進むようにはしたいです。 あとは会場の都合で、もくもく会の割には時間が微妙に短いとかプロジェクタが繋がらないとか見づらいとかコンセントの数少ないとかWi-Fiがないとかもありました。 もくもく会を開催するのに良さ気な会場がなかった(見つけられなかった)のです。 そこそこの広さがあって電源とWiFiとプロジェクタとスクリーンがあって13:00から18:00くらいまで格安で借りられる会場の情報があったら誰か教えて下さい。(お

なお、次回の Nagoya.vim #3 の予定は未定ですが年内にはやりたいなとは思っています。 次回は多少発表とかもするかもしれません。 興味のある方はぜひ!

ターミナル上で unite.vim っぽいことをする peco が大変便利

peco って

タイトルにあるように、ターミナル上で unite.vim っぽいことができるようになります。 標準入力を受け取って、インクリメンタルな絞り込みをして標準出力に投げることができます。 zsh をちょっと書く必要がありますが、任意のソースをインクリメンタルに検索した後任意のコマンドを実行するみたいなこともできます。 他にも似たようなものとして zaw とか percol とかあるっぽいです。 peco が golang で書かれていること以外は違いはよくわかっていません。(お

github のページに行くとスクリーンショットが見れます。

peco/peco

インストール

golang が入っているなら

go get github.com/peco/peco/cmd/peco

で入ります。簡単ですね。

簡単な使い方

ps aux | peco

ps コマンドの結果を絞りこみ検索できます。

zsh で拡張してみた

単純に絞り込むだけじゃなくて、絞り込んだ結果を使っていろいろしたい場合は zshスクリプトを書くと便利です。

準備として .zshrc にこんな感じで書いておきます

[[ -e ~/peco.zsh ]] && source ~/peco.zsh

peco.zsh というファイルに色々書いていきます。

pushd したディレクトリ一覧から選んで cd する

function peco-pushd() {
  eval cd $(pushd | sed -e "s/ /\n/g" | peco)
  zle reset-prompt
}
zle -N peco-pushd
bindkey "^a" peco-pushd

以前いたことがあるディレクトリ位置に簡単に cd できるようになります。 あらかじめ setopt auto_pushd しておくとなお一層便利です。

git log の結果から SHA-1 ハッシュを取得して入力する

function peco-git-log() {
  GIT_COMMIT_HASH=$(git log --oneline --graph --all --decorate | peco | sed -e "s/^\W\+\([0-9A-Fa-f]\+\).*$/\1/")
  BUFFER=${BUFFER}${GIT_COMMIT_HASH}
  CURSOR=$#BUFFER
}
zle -N peco-git-log
bindkey "^b" peco-git-log

たとえば、git checkout -b hoge まで入力した後で、<C-b> を押すと git log の結果が peco で表示されます。 望みのコミットを絞り込んで Enter を押すと、例えば git checkout -b hoge 0123abc みたいな感じで選んだコミット位置からブランチを生やすことができます。 (まぁ、Vim から gitv を使った方が便利だけど)