読者です 読者をやめる 読者になる 読者になる

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

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

VimConf 2014 に行ってきたよ

Vim

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 を開催してきた

Vim

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 が大変便利

zsh

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 を使った方が便利だけど)

Osaka.vim に行ってきたよ

この前の土曜日に Osaka.vim というのがあって、 「名古屋からすれば大阪なんて近所みたいなもんやろー」と思ってノリで行ってきました。

thinca さんのライブコーディング

quickmemo.vim というプラグインをライブコーディングしてました。 僕はこのプラグインの仕様とかよりも thinca さんのコーディングの仕方や Vim の設定の方ばかり目がいっていました。 p で貼り付けた部分がハイライトされるやつとか便利そうだと思って聞いたら、yankround.vim の機能だそうです。 yankround 便利そう。 あと、日本語入力が SKK でした。 あとあと、Vim script の関数とかスラスラ書けるあたりはさすが thinca さんすごいと思いました。

自由時間

もくもくタイムなのかと思っていたのですが、割とみんないろんなことしゃべってい賑やかでした。 僕は去年の末から開発がストップしていた某 Git 系プラグインの開発を再開すべく、自分が書いたコードを一生懸命読んでいました。 進捗は0でしたが、とりあえず開発再開の目処は立ったので良かったかなと。

LT のような何か

ゲリラ的に発表が始まっていました。 kozo2 さんのは T-Code とかいう日本語入力方法の話でした。これは近づいちゃいけない奴だと思いました。(褒め言葉)

itchyny さんは miv という自作のプラグインマネージャを紹介されていました。 これの面白いとこはなんと Haskell で書かれているところ。Vim プラグインというよりは Vim script 生成コマンドツールですね。 こういう仕組みはいろいろ応用できそうです。(しかし、現時点では特に思いついていない)

haya14busa さんはプラグインの作り方という感じの発表をされてました。 Vimプラグイン作ること自体の敷居はそこまで高くないよという旨の内容でした。 これを機にプラグイン開発者がどんどん増えればよいですね。

懇親会

お好み焼き美味しかったです。

帰りの新幹線

終新幹線で帰りました。 ちょうど車内にいるときに vimrc 読書会が始まったのでそれにも参加しました。 あと、なんと奇遇にも kyon_mm さんとばったり遭遇したりもしました。

おわりに

Osaka.vim とても楽しかったです。 新幹線ですぐ行けちゃうのでまた機会があったら参加したいです。

Nagoya.vim もそろそろ第2回を開催したいなと思いました。 (あとは会場さえあれば...)

Arch Linux (64bit) における SML# のビルド

どうやら巷では SML# をビルドするのが流行っているようなので、僕も乗っかってみました。 僕のメイン環境は Arch Linux (64bit) なのですが色々試行錯誤したらビルドできたので記録として残しときます。

Xubuntu 64bit でのビルドは、すでによんたさん (id:keita44_f4) が成功させているので僕もそれを参考にしました。

Xubuntu 64bitにおけるSML# 2.0.0のビルド - ししちにじゅうはち 4x7=28

32bit 用の gcc のインストール

32bit のバイナリを吐き出すために gcc-multilib を入れます。

sudo pacman -S gcc-multilib

普通の gcc とコンフリクトするというメッセージと共に上書きするか聞いてくるので yes と答えます。 なお、32bit のバイナリをインストールするには/etc/pacman.confmultilibリポジトリを有効にする必要があります。

GMP ライブラリのインストール

Arch Linux なら 32bit 版でもバイナリがあります。

sudo pacman -S lib32-gmp

LLVM ライブラリのインストール

Arch Linux なら 32bit 版でもバイナリがあります。

sudo pacman -S lib32-llvm

SML# のビルドの前に...

SML# のビルドでは LLVM 関連のパスを取得するのに llvm-config という実行ファイルを使っているみたいなのですが、Arch Linuxpacmanlib32-llvm をインストールした場合は llvm-config32 という名前になります。 これに対応させるため、SML# のソースに含まれる configure ファイルを編集します。

# configure の 4288 行目くらい
- set dummy llvm-config; ac_word=$2
+ set dummy llvm-config32; ac_word=$2

SML# のビルド

ここまでくればあとは SML# をビルドするだけ! ちなみに pacman 経由で 32bit バイナリを入れると /usr/lib32 以下にものができるのでそれをオプションで指定してやります。

./configure CC='gcc -m32' CXX='g++ -m32' \
    LD='ld -m elf_i386' \
    LDFLAGS='-L/usr/lib32' \
    --prefix=/opt/smlsharp-2.0 
make
sudo make install

まとめ

  • やっぱり 64bit は茨の道だった
  • そもそも SML# 書いたことないし文法も知らない
  • やってみたらできました

Vim で Coq 環境を整える

Vim Coq

はじめに

昨日、スタート Ssreflect というイベントに参加して、Coq + ssreflect のハンズオン的なものをやりました。 Coq 環境といえば、Emacs の ProofGeneral が非常に有名です。 しかし、私は Emacs は終了の仕方すら分からないレベルの初心者なので Emacs + ProofGeneral ではチュートリアルの例題を打ち込むだけでも非常に苦労しました。

証明も普段使い慣れている Vim で何とかできないかと思い調べたところ、そこそこ良さ気な環境を構築できたので紹介します。

使用するプラグイン

以下の2つをインストールします。NeoBundle のようなパッケージマネージャを使用するのをおすすめします。

jvoorhis/coq.vim は Coq のシンタックスとインデント設定を追加するためのプラグインです。 vim-scripts/CoqIDE は Vim 上で CoqIDE の動作をエミュレーションするプラグインです。内部では coqtop を使っているようです。

インストール方法

NeoBundle 'jvoorhis/coq.vim'
NeoBundleLazy 'vim-scripts/CoqIDE', {
\ 'autoload' : {
\   'filetypes' : 'coq'
\ }}

使い方

Vim拡張子 .v のファイルを開くと自動的に色付けされるようになります。 適当に証明を書いて :CoqIDENext を実行すると、証明をひとつ進めることができます。 すると、Window が分割されて CoqIDE と同様に現在の情報が表示されるようになります。 証明をひとつ戻すには :CoqIDEUndo を使います。 :CoqIDEToCursor とするとカーソル位置まで証明を進めます。

f:id:cohama:20140427193733p:plain

色を変える

vim-scripts/CoqIDE のデフォルト設定では証明が済んだ部分の色はライトグリーンになっています。 これは白背景のカラースキームでは良いのですが、黒背景の場合は非常に見づらいです。 これを解決するには vimrc に下記のようにハイライト設定を書きます。

autocmd FileType coq highlight SentToCoq ctermbg=17 guibg=#000080

おわりに

Vim でも結構いい感じに Coq の環境が整えられました。 まぁ ProofGeneral と比べると (多分) 機能的に劣っているとは思いますが、どうしても Vim で証明したい人は試してみてはいかがでしょうか?

fugitive.vim をもっと使いこなす

この記事は Vim Advent Calendar 2013 の 16 日目の記事です。 昨日は id:deris さんの Vimmerなら2013年中に試しておきたい海外産Vim plugin 8選 - derisの日記 でした。知らないプラグインあったので時間ができたら試してみたいですね。

進捗ダメです

すみません。本当は自作プラグインを大々的に紹介するつもりだったのですが、進捗ダメでした。今日は fugitive.vim の小ネタについて書きます。 次回作にご期待ください。

fugitive.vim について

Vim から Git を便利に使うプラグインです。詳しくは

みたいなところを参照してください。 とりあえず、git status 見たり、git add -pVim の diff 機能を使って実行できたりしてとても便利です。

リポジトリのルートに cd する

あまり知られていないような気がしているのですが、

:Gcd

リポジトリのルートに :cd することができます。

:Gedit を使って違うリビジョンのファイルを開く

git を使っていると、違うブランチにあるファイルを開きたくなりますね。Gedit でできます。

:Gedit feature-branch:path/to/file

<リビジョン>:<ファイル名> で特定のリビジョンの特定のファイルを閲覧することができます。ただ、このコマンドは :edit 相当なので現在のウィンドウで開きます。他には :vsplit 相当の :Gvsplit などがあります。

: の前はリビジョンを指定します。ブランチ名や HEAD^ のような指定の仕方以外にも fugitive.vim が定義する便利な記法が使えます。

例えば、~3 だけで HEAD~3 と同様の意味になります。詳しくは :help fugitive-revision

そして、これらのコマンドはブランチ名およびファイル名の補完が効きます。ファイル名の補完に至っては、現在のワーキングディレクトリになくても入力したリビジョンにあれば補完されます。

:Gdiff で違うリビジョンとの diff を取る

:Gdiff といえば、git add -p がとても便利ですが、別リビジョンにある同ファイルとの diff を取ることもできます。

:Gdiff feature-branch

例えば、:Gdiff developdevelop ブランチとの diff を取ったり、:Gdiff ~3 で 3 つ前のコミットと diff 取ったりできます。

おわりに

  • 進捗ダメです
  • fugitive.vim は内部の実装汚いけど便利

明日は @cocopon さんです。