ujihisa.vim #3 へ行ってきました。

先日、ujihisa.vim #3 に参加しました。発表資料は既に公開していますが、せっかくなので感想をまとめておこうかと思います。

KoRoNさん vim-jpの活動報告

vim-jpの現在、過去、未来をまとめた発表でした。よくまとまっていたと思います。最近、自分は忙しくて vim_dev にパッチを送ることができてないので、そろそろやりたいですね。

basyuraさん TweetVimの話

TweetVimの歴史と、これまでに追加された機能について。開発を始められてから一年くらいになるみたいですが、多くの新機能が追加されているらしく、vimshell+earthquake.gemで満足している私もちょっと使ってみたくなりました。

thincaさん vital.vimについて

thincaさんによるvital.vimの発表。自身が作成したVim pluginを使っての発表でした。なかなか新鮮です。vital.vimはプラグイン開発者のためのライブラリなので、会場にいらっしゃっている皆さんにはあまり意識することはないと思いますが、いろんなVim pluginに使われだしたので接する機会は多いはずです。私自身、vitalの開発にはあまり関われていないので、そろそろどうにかしないといけないと思っています。

ujihisaさん neosnippetの紹介

ujihisaさんによるneosnippetの紹介です。neosnippetは最近になって開発が加速しているので、「追いつかない」と悲鳴を上げられていたようですが、よくまとまっていたと思います。私は開発者なので、neosnippetの機能は全て分かっているのですが、ujihisaのneosnippetの使い方がなかなか新鮮で、私にも参考になりました。

完全匿名主義さん　マクロ漁船にのろう

今回のダークホース的な発表。「Vimのマクロはチューリング完全なのでBrainF*ck処理系も実現できる」ちょっと何を言っているのか分かりませんでした。私はVim scriptで大体満足しているので、マクロはいいかな……。

rbtnnさん Hexriptについて

Hexriptは私も開発に協力しているプラグインです。Hexriptはかなり面白いコンセプトだと思うのですが、会場にはバイナリアンが少なかったので、それほど興味を持たれなかったようなのが残念です。vitalへの字句解析ルーチンのマージ、頑張ってください。vimshellでもそれを使いたいですね。

deris0126さん 効率的なカーソル移動について

カーソル移動というのは基本ですが、Vimmerが一番こだわりを持っている部分といっても過言ではないでしょう。Vimにたくさんある移動コマンド、それらをどう使いわけるか、というのは大変参考になります。私ももうちょっとこだわってみたくなりました。

Shougo(自分) neobundle.vimについて+おまけ

http://www.slideshare.net/Shougo/neobundlevim

スライドは公開しているので、上記を参照してほしいと思います。vimfilerかneobundleのどちらを発表しようかと迷っていたんですが、neobundleについてきちんと知っている人がなかなかいないということと、neobundleは最近機能が完成したので、披露するなら今だろうと思い、発表することにしました。今回のスライドはneobundleのマニュアル代わりにもなるように、私のスライドにしては珍しく、機能の解説を多めにしています。ただ、まじめなスライドだけだと、期待して来てくださった方やVim pluginに興味がない人に申し訳ないと思ったので、最後にちょっとだけオマケを仕込むことにしたのです。えっ、おまけが本編だろうって？　私は真面目な発表を(ry

感想

全体的な感想としては、やはり面白かったです。普段、これだけVimmerと接する機会はなかなかないし、他の人の発表を聞くだけでいろいろインスピレーションが刺激されます。neobundle.vimも大体完成したと思っていたんですが、他の人の感想とかを聞いてみるとまだまだ改善の余地があることが分かりました。これからもVim plguinの開発を続けていきたいですね。

neocomplcache-snippets-complete は neosnippet になりました

こんにちは。Shougoです。最近、またブログをさぼり気味ですが、今回は比較的大きな変更があったので
ブログにまとめておこうと思います。

本日、neocomplcache-snppets-complete は neosnippet にリネームされました。

https://github.com/Shougo/neosnippet

それに伴ない、旧 neocomplcache-snippets-complete は一部仕様を変更した上で残されました。

https://github.com/Shougo/neocomplcache-snippets-complete

まだ使用することはできますが、起動時にメッセージが表示されます。

リネームの理由：

さて、皆さんが気になるのは、「なぜリネームしたか」ということでしょうから簡単に説明しておきます。

一番大きな理由としては、neocomplcache-snippets-complete は巨大になりすぎたからです。neocomplcache-snippets-complete は私がスニペットを勉強するために開発を始めたプラグインでした。当時の私はスニペットプラグインの恐ろしさを知らなかったので、軽い気持ちでneocomplcache の一部として開発していました。

しかし、スニペットプラグインというのは複雑すぎました。要望の量は neocomplcache の次に多く、それに答えるうちに neocomplcache-snippets-complete は肥大化し、ついに
neocomplcache 本体から分離されることとなりました。

本体から分離されても neocomplcache-snippets-complete は巨大になり続け、ついにneocomplcache から独立することになりました。neocomplcache への依存をなくし、一つのスニペットプラグインとして再出発することになったのです。

もう一つの理由としては、neocomplcache-snippets-complete という名前が長すぎたからです。neo シリーズなスニペットプラグインという位置付けをするため、neosnippetという名前になりました。

主な変更点：

neosnippet の変更点は以下の通りです。

1.  名前が変更された
2.  バグが修正された
3.  新機能が追加された
4.  vital 化された
5.  変数名、コマンド名、キーマッピング名が変更された
6.  内部実装やインタフェースが整理された
7.  neocomplcacheに依存しなくなった

よくある質問：

Q: vim.org にある neocomplcache-snippets-complete はどうなるの？

A: 警告入りのバージョンをアップロードするか検討中。neosnippetはいずれ vim.org にもアップロードします。

Q: neosnippet のマーカーはどうするの？

A: neosnippet はマーカーを使用するスニペットプラグインとして有名でした。ただ、最近はマーカーを使用することによる問題点もいくつか明らかになっています。例えば、マーカーで実現できないものとして「プレースホルダのスキップ、逆方向へのジャンプ」、マーカーでは実現するのが難しい機能として「プレースホルダの変換」が挙げられます。ただし、マーカーを用いる利点もあり、「どこにジャンプするのか分かりやすい」「入れ子のスニペットに対応できる」「テキストを盛大に変更しても、マーカーが残っている限りジャンプできる」というのが挙げられます。マーカーが好きでなければ他のスニペットプラグインを用いればよいわけで、現在は対応を保留中です。つまり、まだマー
カー方式のままです。何か良い案があれ ば教えてください。

Q: neocomplcache-snippets-complete との互換性は？

A: neosnippet でも neocomplcache-snippets-complete と同じコマンドやキーマッピング、変数が使用できます。ただし、これらは新しい名前が推奨されています。将来的に互換機能が削除される可能性もありますので、注意してください。スニペットファイルの文法に違いはないので、スニペットファイルは全く同じものが使用できます。ちなみに、neosnippet は neocomplcache-snippets-complete とは共存ができません。

Q: これからの neosnippet はどうなるの？

A: neocomplcache-snippets-complete は開発が凍結されますが、neosnippet の開発はこれまで通り継続されます。最近だと、ujihisaさんが開発に加わってくれています。

Shibuya.el の感想と(LT？)スライドの公開

先日行われた、Shibuya.elに参加してきました。残念ながら、Ustream等は行われなかったので、会場へ行けなかった皆さんはいったいどんな発表があるのか気になっていることでしょう。他の人も何人か感想記事を載せているようですが、思ったよりも少なかったので、私も感想記事を書いておこうと思います。

ainame            :  初めてのemacs lisp

ainameさんは、Shibuya.el を開催するために、Emacs Lisp を覚えたそうです。すごいですね。作ったのは、「hjkl-mode」という Emacs で vi キーバインディングを提供するメジャーモードのようです。コードを読む機会が多いので便利だそうです。この発表を聞いて私は、るびきちさんが以前設定を紹介していた、「view-modeでhjklで移動する設定」を思い出しました。

uk_ar               :  「Emacs Lispのテスト」について

Emacs標準のテストフレームワークであるERTの紹介です。テストフレームワークは作ったものの、なかなかテストを書けていない私には耳が痛い話でした。この発表を聞いて、私ももっとテストを書きたいと思いました。

Hiroaki Nagata : emacsとdvorak配列について

dvorak配列の宣伝でした。キーボード配列も一種の宗教ではないかと個人的には思います。こだわりのある人も多いですが、私はキーボード配列を変更するのはVim内だけで十分ですね……。

Yuto S Hayamizu : tokyo-emacs という歴史上の出来事

twittering-modeのはやみずさんの発表。さすがに発表がうまかったです。ホモ・イーマクスとホモ・ヴィムで吹きました。なぜ tokyo-emacs が無くなってしまったのかがよく理解できる話でした。勉強会は運営者に負荷が集中しがちなので、どうにかしたいところですね。これは別にEmacs勉強会に限った話ではなく、Vim勉強会でも問題になっている気がしています。

m2ym                    :最近作った拡張（popwin.elなど）について

LTなので時間は短かったはずなんですが、内容は濃く、よくまとまっていたと思います。m2ymさんのプラグインが実際に動いているところを見れてよかったです。Ruby 1.9対応のRSenSeの次期バージョンとか、新たな拡張機能の話とか、今後がとても気になる発表でした。

at_aka                    : clgrep.el について

前半はkinesisの宣伝w。後半はChangelogメモと、Changelogメモに特化したgrep拡張の話。エディタの中でメモを取る機能は一定の需要がありますよね。

ShougoMatsu　　　 : 「Vimmerから見たEmacs」

私の発表です。

スライドの内容は見てもらったら分かると思います。

あ…ありのまま 今　起こった事を話すぜ！
『おれはShibuya.elのためにLTを作っていたと思ったらいつのまにか基調講演になっていた』
な…　何を言ってるのか　わからねーと思うが
おれもどうしてこうなったのかわからなかった…

しんぱいしていましたが、こうひょうみたいでよかったです

懇親会

本日のメインです。私はずっとVimについて語っていたような気がします。「酔っているんですか？」と聞かれましたが、私は会場でお酒を飲んでいません。しいていうなら、「Vimに酔っていました」。
とりあえず、議論になったのはこういう話題です。

Vim(Emacs)でご飯を食べていくには
情熱Vimmer
仕事とVim(Emacs)
Vim(Emacs)拡張開発での苦労
勉強会主催者はマゾ
拡張機能のテストどうする？
m2ymさんと拡張機能開発あるある

印象に残ったやりとり：
私「m2ymさんはデフォルトのキーバインドを大事にされているのなら、もちろん<C-h>もそのままなんですよね？」
m2ym「いや、それはさすがに無理。私はヘルプをそんなに開かないんで」
「<C-h>はキーマッピングを変更させるための陰謀ではないか」

Emacs 勉強会に参加するのは初めてでしたが、特に Vimmerだから差別されるといったことはなく、和気あいあいと議論に参加できたと思います。また次回があれば、ぜひ参加したいですね。そのときには、自分の作ったVim のプラグインをEmacs ユーザに向けて紹介してみたいと思っています。

unite.vim ver.4.0の変更点について

おひさしぶりです。Shougoです。 ver.3.1のリリースから4ヶ月近くが経ってしまいましたが本日、無事にunite.vim ver.4.0をリリースすることができました。 メジャーバージョンアップということもあり、今回のリリースにはver.3.1と比較して多くの機能が実装されています。 「unite.vimの変更点をまとめてほしい」という声があったので、今回はunite.vimにどのような変更点があったかを解説していこうと思います。 もちろん、unite.vimには追加できなかった機能も数多く存在します。それらは今日より実装を開始したunite.vim 4.1以降で実装を開始する予定です。

 

1: ドキュメントの英語化

内部ドキュメントが完全に英語化されました。この決定は賛否両論あるでしょうが、 unite.vimの日本語情報はたくさんありますし、Vimテクニックバイブルで勉強することもできます。 ドキュメントが日本語になっていなくても、ある程度なんとかなるだろうと判断をしました。 私にとっては、unite.vimの存在が外国人にほとんど知られていないことが問題になっています。 unite.vimのことをよく知ってもらえるためには、まずドキュメントを充実させなければなりません。 英語化は必然だったのです。日本語ドキュメントを同時にメンテナンスすると、作業量的につらいので削除することになりました。 誰かが翻訳する、ということを提案していた人も居ましたが、unite.vimの更新には付いていけないでしょうから それには期待していません。もちろん、他の人からの英文の改善は歓迎しています。

 

2: 速度の最適化

 今回のリリースの最大の変更点です。具体的には、uniteバッファを開く速度や絞り込み速度、描画速度が大幅に改善しています。 特に候補が多いときに効果を実感できることでしょう。ctrlp.vimの実装を研究したので、おそらくctrlp.vimと同程度の速度にはなったはずです。

 

3: vimfiler対応の改善

vimfiler対応はunite.vim ver.3で行っていましたが、それをより改善しています。 具体的には、unite-sshに対応したりしました。

 

4: unite#custom_source()の追加

unite#custom_source()を追加しました。この関数を使用すると、sourceの振舞いをある程度カスタマイズすることができます。

 

5: multilineの改善

multilineの処理を改善しました。grepやregister, history/register sourceがmultilineの候補に対応しました。

 

6: unite-command, unite-mapping の改善

細かな挙動を改善しています。さらに、previewアクションを実装しました。

 

7: カーソル移動処理の改善

カーソル移動の動作がより直感的になりました。

 

8: -auto-quitオプションの追加

-auto-quitオプションが追加されました。:Unite -auto-quit neobundle/updateなどとすると、幸せになれるかもしれません。

 

9: -keep-focusオプションの追加

-keep-focusオプションが追加されました。このオプションを有効にすると、コマンドの実行後にフォーカスを移動しません。

 

10: vimfilerのための変更

最新版のvimfilerのための変更がかなり入っています。vimfilerを使用しているなら、アップデートは必須でしょう。

 

11: 多数のバグ修正

いつもの。

x86勉強会#2のスライドを公開しました（補足付き）

昨日(5/26)はx86勉強会#2でした。
他の人の発表内容については、他の人のブログ記事に期待するとして、私は当日の
発表スライドを公開しようと思います。

------------------------------------------------------------------------------------------

第一部：帰ってきたvinarise : Vim X バイナリ = 最強   (二ヶ国語放送)

# はじめに

* 今回のスライドは世界初！？(バイナリ/日本語)の二ヶ国語放送でおおくりしています。
* つまり、日本語よりバイナリのほうが堪能であったとしても大丈夫
* バイナリアンにやさしいプレゼンテーションです
* スライドの再生にはvinariseを使用しています(セルフプレゼンテーション)
* vinariseはプレゼンテーションツールだったんだよ！(な、なんだってーーAA略)

# 自己紹介

* 知っている人も多いと思いますが……。
* Shougoです。
* 伝説的なプレゼン「Vim = VM」
* Twitterでは@ShougoMatsuとして活動しています。
* 「迷言：Vimは家族」
* Blog : http://vinarian.blogspot.com/
* Vim大好き
* Vim病にかかって4年経ちますが、日々症状は悪化しています
* Vim勉強会以外にもたまに出没する(たとえばこの勉強会とかね！)
* 今日はx86/Vim勉強会と聞いてきました

# vinariseとは？

* Vim上で動作するバイナリエディタプラグイン
* ブイナライズと発音する
* 名前の由来は、Vim + Binary + Analyse
* ただのバイナリエディタではない。解析ツールを目指す。
* 全く宣伝してないのに、外国のユーザが居たりする。よく分からない。

# なぜvinariseを開発したのか？

* テキストエディタはバイナリファイルくらい開けないといけない
* Vimにはxxdがある。しかし機能がショぼい
* Vim pluginと連携したい
* 日本語対応させたい
* 巨大ファイル開きたい
* じゃあ自作するしかない(死亡フラグ)
* Emacsのhexl-mode?なにそれおいしいの(正直比較にならない)

# vinariseの特徴

* マルチプラットフォーム
* 巨大ファイルを開ける
* 日本語ファイル対応
* ビットマップビュー
* プラグインで拡張可能
* バイナリファイル自動認識

# Emacs hexl-modeとの比較(ネタ)
* hexl-modeは数十メガバイトのファイルを開くとフリーズ
* hexl-modeは日本語に対応していない(外国産のバイナリエディタにありがち)
* バイナリエディタとしての機能が圧倒的に足りない
* ぶっちゃけ、xxdにGUIを付けたような(以下自主規制)

# vinariseの歴史
* 昔はxxdを使っていた
* 2010年5月頃　Kernel/VM勉強会でバイナリアンに興味を持つ
* アイディアを収集しながら作成開始
* 2010年8月頃 x86勉強会 #1で披露する
* 協力者が徐々に集まる
* 長い停滞(やる気なし)
* 2011年9月頃　Vimテクニックバイブルにvinariseのことをちょっとだけ載せる
* さすがに開発しないと詐欺と思われそう
* 2012年1月頃　開発再開する
* いろんな機能を付け、当初のものとはほとんど別物に
* 現在に至る

# vinariseのインストール方法

* githubから取ってきましょう。
* 今ならneobundleを推奨
  NeoBundle 'Shougo/vinarise'
* VimのPythonインタフェースが必須
  あなたのVimを:echo has('python')で確認してみましょう。

# vinariseの簡単な使い方
* A: ファイルをVimで開き、:Vinarise

* B: :Vinarise {ファイル名}

# vinariseの機能
* マルチプラットフォーム
* 巨大ファイルを開ける
* 日本語ファイル対応
* ビットマップビュー
* プラグインで拡張可能
* Vim pluginとの連携
* バイナリファイル自動認識

# 巨大ファイルを開ける
* vinariseはメモリマップを利用して、1GB程度の巨大ファイルを一瞬で開くことができる
* xxdやEmacs hexl-modeでは無理
* ghexでイメージファイルを開こうとしたらフリーズしました……
* bviや大半の外国製バイナリエディタでは無理
* 大事なことなので三回説明した
* ちなみに、バッファは現在見ているところしか行を生成しない
* Vimは行が多かったりすると重いが、vinariseは脅威のVim scriptテクノロジーによっ
 て重くない
* デモ：Ubuntu 12.04 LTS 日本語Remix CD(700MB)を開く

# マルチプラットフォーム
* Windows界では需要のおかげか、バイナリエディタがたくさんある
* しかし、Mac界やLinux界には不足している
* vinariseは基本的にVimとPythonさえ動作する環境ならどこでも動作する
* 他のバイナリエディタに対する圧倒的アドバンテージ！
* Androidでも動作する……とよいですね(未確認)

# 日本語ファイル対応
* vinariseはもちろん日本語ファイルを開くことができる
* 対応エンコーディング：UTF-8, UTF-16BE/LE, cp932, EUC-JP
* ただし、初期はASCIIモード
* Eを押してエンコーディング形式を指定する
* :Vinariseの引数 --encoding=で指定してもよい
* 実装はかなり頑張ったので、日本語ファイルだから遅くなるということはない
* デモ：vinariseで日本語ファイルを開く

# ビットマップビュー
* みんな大好きなビットマップビューにも対応している
* Vimで目grep! みんなの夢
* 使い方はvinariseのバッファで":VinarisePluginBitmapView"コマンドを実行するだけ
* GVimだとフォントが小さくなり、よりそれっぽくなる
* ASCII, コントロールコード, マルチバイトコードを判別
* デモ

# プラグインで拡張可能
* vinariseはプラグインによる拡張機能がある
* 実際に、s_yukikazeさんによりPEを解釈するプラグインが作られている。
  https://github.com/s-yukikaze/vinarise-plugin-peanalysis
* いろいろ忙しくて、プラグインの仕様はドキュメント化されてない
* 作ってみたくなったら、BitmapViewのプラグインのソースコードを見ると良い。

# Vim pluginとの連携
* vinariseはVim pluginと連携できる
* vimfilerで、Bを押すとvinariseで開く
* 他にもやってみたいとは思っているのでアイデア募集中

# バイナリファイル自動認識
* .vimrc内でlet g:vinarise_enable_auto_detect = 1とする
* 「:edit バイナリファイル」を実行すると、開いたファイルがバイナリファイル
っぽかったら自動で認識してvinariseで開く。
* ELFっぽかったら、objdumpで開く
* デモ

# vinariseの制限
* 1.6GB以上のファイルは開けない(仮想メモリの制限)
* バイトの挿入・削除はできない
* バイト列を型変換して表示することはできない
* ファイルの保存は遅い
* アンドゥできない

# 今後のvinariseについて
* 2GB以上のファイルへの対応
* ファイルの保存を高速にする
* バイトの挿入・削除への対応
* ISO-2022-JP文字コードへの対応
* バイト列の型表示はプラグインでやる予定
* アンドゥを実装する
* バイナリの構造を表示(バイナリファイルのアウトライン表示)

# 終わりに
* 今日覚えて欲しいこと「Vimは優秀なバイナリエディタ」である
* 「hexl-mode, xxd？　なにそれおいしいの」
* vinariseを使うと、Vimをバイナリエディタにすることができます
* みなさんも使ってみた感想があれば、@ShougoMatsuまで
* ただし、あまりに無茶な要求はしないようにしましょう
* Vim + Python縛りはつらいのです
* 業務で使用できるような高機能なバイナリエディタ(解析ツール)というのは金が取れるレベルです
* これを機会に、みなさんもHappy vinarise!

------------------------------------------------------------------------------------------

第二部：Vimネタスライド

何も言わず、リンク先のスライドを見てほしい……。
http://www.slideshare.net/Shougo/vim-13092304
どう思う？　すごく、Vimです……。
うん、またなんだ。すまない。もはや謝って許してほしいとも思っていない。
しかし、vinariseのおかげでVimに興味を持った人ならきっと楽しんで貰えると思ってこ
のスライドを用意したんだ。

------------------------------------------------------------------------------------------

ネタスライド補足

私としてはみなさんに楽しんでもらえるよう、万全を期して用意をしたはずなのですが
、Twitterの感想を見ていると一部の人が私の発表に不満を覚えているようです(特に第
二部について)。

このまま誤解されているのも、何だか悲しいので私の発表の真の意図をここで説明した
いと思います。ちなみにネタばれ全開なので、私の発表をまだ見ていない人はすぐに回
れ右をするんだ！



















* 私の発表内容は私の個人的見解であり、私の発表にいかなる不満を持ったとしても
Vimや他のVimmerに対して悪い印象を持たれないでください。私はただの一人のVimmer
にすぎません。
* 少なくとも前半はバイナリエディタ(とVim)の話をしました。この内容自体は問題ない
はずです。
* 第二部はほぼVimオンリーの話になっていますが、それはオマケスライドだからです。
自分の発表でVimに興味を持った人がいるかもしれないので用意しました。事前に聞いて
みたところ、Vimを日常的に使用している人も多くいました。
* 最初から内容を公開してしまう手もありましたが、ネタばれすることでつまらなくな
ると思い、それは避けました。最後に発表を持ってきたり、発表時間が他の方よりも長
いのは、ある意味の予告だと思ってください。※1ただ、当日にアナウンスくらいはしても
よかったかもしれないです。
* このスライドは一ヶ月以上前から作成していて、練習もきちんとしていました。決し
て半端な気持ちで作っていたわけでありません。というより、半端な気分ならあの場で
発表できないでしょう。※2
* x86勉強会でVimの話をしたのは、普段バイナリを扱っている方々にもVimのことを知っ
てもらいたかったからです。Vim勉強会でVimのことを話すよりも良いアピールになると
思いました。私はバイナリ技術も好きなので、バイナリとVimの橋渡しをしたかったので
す。

※1：私の後での発表は誰もやりたくないと思います。
※2：ちなみに、私はKaoriya-Vimを配布しているKoRoNさんから「鋼の心臓を持っている
」認定を受けました。

以上になります。真意を汲み取っていただければ幸いです。
ちなみに、懇親会で私の発表の感想を聞いてみると、好意的に受け取ってくれる人が
多かったようでした。それを聞いて、やって良かったと思いました。
------------------------------------------------------------------------------------------

「Emacs 実践入門」は現時点で最良のEmacs入門書である

これは技術評論社より出版された、「Emacs実践入門」に関するレビューです。
私はVimmerですが、これまで出版されたEmacs本のほとんどは読んだことがあります。そういう視点からレビューしたいと思います。

一言でいうと、この本はEmacsの入門書として最適です。
Emacsの本はこれまでいくつか出てきていますが、初心者が読むのに適した本はなかなかありませんでした。

O'Reillyから出ている入門GNU Emacs第三版はよい本ですが、Emacsの基本操作とEmacs標準のEmacs Lispしか書いていません。
さらに出版からもう9年も経つため、内容が古くなってきています。
Emacsテクニックバイブルは拡張機能のカタログであり、Emacsの入門用の書籍ではありません。
Emacs Lispテクニックバイブルは既存の拡張に飽き足らない人が自分でEmacsを拡張するための本です。

このEmacs実践入門はそこまでページ数が多くないにもかかわらず、
Emacsの基礎からEmacsの拡張するEmacs Lispパッケージの紹介まで一通りの解説がされており、賞賛に値します。
この本は最新のEmacs 23/24に準拠しているため、もし出版から年月が経ってもある程度対応できることでしょう。
まだ正式なリリースがされていないEmacs 24についての情報は貴重であり、この本の価値をより一層高めています。

読んでみて驚いたのは、Emacs設定ファイルの記述方法や管理の仕方がとても詳しく書かれていたことです。
今まで自分が知りたいと思っていた情報がよくまとまっていました。
特に、Emacs 24より搭載されるEmacs Lisp Package Archive(ELPA)の解説は貴重です。
anything.elの解説も、Emacsテクニックバイブルほどではありませんが、充実しています。

この本の最後の章では、Emacsの各プログラミング言語用のメジャーモードが細かく解説されています。
メジャーモードはEmacsテクニックバイブルや入門GNU Emacsでも一部解説されていたと思いますが、
これほど分かりやすく、しかも最新のEmacsに準拠して書かれてはいませんでした。
Emacsは各プログラミング言語用のメジャーモードが乱立しており、どれを使えばいいか分からないような状況に陥ることがよくありました。
しかし、この本に書いてあるメジャーモードを導入していれば間違いはありません。
この章はあまり期待していませんでしたが、よく出来ていたのでポイントが高いです。

私がEmacsに出会ったときにこの本が存在し、Windows環境でのEmacsが今ぐらいに使いやすくなっていたなら、
私がVimではなくEmacsを使っていた未来もあったかもしれません。

ちなみに、私がVimmerやEmacs使いに一冊だけEmacsの本を勧めるとしたら、間違いなくこの本を勧めます。
この本に物足りなくなった人は、EmacsテクニックバイブルやEmacs Lispテクニックバイブルを購入すると良いでしょう。
久しぶりに購入して満足した書籍でした。技術書を執筆した一人として、執筆の困難さは痛いほど分かるため、
この本を執筆したtomoyaさんに最大限の賛辞を送りたいと思います。

※：この本ではEmacsのIMとしてSKK(おそらくddskk)を勧めていましたが、初心者にSKKを勧めるのはどうかと思いました。
SKKは設定が複雑だし、慣れるのに時間がかかるため、初心者にはオススメできません……。

neocomplcache Ver.7の新機能とその設計思想について

本日、別ブランチで開発していたneocomplcache Ver.7をmasterにマージしました。
自分でしばらく使っていて、特に問題が起こらなかったため、広く使ってもらう必要があると感じたためです。

Ver.6.2からVer.6.3ではなくVer.7.0になったということは、大きな意味があります。
つまり、後方互換性や安定性に関わる変更が入ったということです。
大きな問題がないことは分かっていますが、何か未知の問題が生じる可能性があります。
注意してください。そしてもし問題が発覚した場合、早めに[作者]に連絡してください。

今回の変更点は以下のようになります。

1：snippets_completeが本体から分離された
おそらく、皆さんが感じる一番の変更点がこれです。
neocomplcacheはスニペット機能が標準的に搭載されていることをウリとしていた時期もありましたが、
今回本体から分離することにしました。

https://github.com/Shougo/neocomplcache-snippets-complete

分離した理由は、snippets_completeの機能が巨大化しすぎ、バグ報告や機能追加の要望を受けた際に
どちらの問題なのかが分かりにくくなってきたからです。
さらに、スニペット機能は使う人と使わない人の差が激しいため、本体に同梱するには適しません。

2：変数名をリファクタリングした
変数名にsourceではなく、pluginという記述が一部残っていたので、それを訂正しました。
これまでの変数名も一応初期化するときに認識するようにはなっていますが、新しい変数名を使用することをオススメします。
正確な変数名についてはneocomplcacheのドキュメントを参照してください。


3：日本語ヘルプが削除された
変数名のリファクタリングやsnippets_completeの分離により、ドキュメントにかなりの更新が入りました。
日本語ヘルプと英語ヘルプに同時に変更を入れるのはつらかったため、日本語ヘルプを削除することにしました。
これには賛否両論あるでしょうが、作者として二つのドキュメントを同時に更新するのは大変なのです。
「『メンテナンスしていない』と注釈を付けて残せばいい」という意見もありましたが、
私にとって初心者がメンテナンスされていないドキュメントを読んでハマるという自体は避けたいと思いました。
最近、vimprocやvimshellにおいても日本語ドキュメントが削除されたのはこれが理由です。

4：パフォーマンスが最適化された
g:neocomplcache_release_cache_timeにより、一定時間経ったキャッシュは自動的に解放されるようになりました。
これにより、neocomplcacheがメモリをたくさん食うという問題は解決するはずです。
さらに、一部の実装を削除・最適化して、補完のパフォーマンスを向上させています。


追記：neocomplcache Ver.7.0の変更ではありませんが、先日リリースしたneocomplcache Ver.6.2で補完関数の挙動が変わったため、
不具合を生じている人がいるようです。「Vimではuim-skkで日本語を入力している」環境で報告を受けています。
その場合、let g:neocomplcache_enable_prefetch = 1とすることで以前の動作に戻すことができます。
ただし、これを設定すると既存の補完関数と互換性がとれなくなるため、作者としてこの設定を推奨する訳ではありません。

Shougo/clang-completeの改名と現在の問題点まとめ

こんにちは。Shougoです。
今後はプラグインの重要な更新点については、ブログにフォローしていくことにしました。

第一弾はneocomplcacheプラグインclang-completeのリポジトリ名変更です。

Shougo/clang-completeとなっていましたが、これだと本家clang-completeと似ていて紛らわしいのでShougo/neocomplcache-clangと名前を変えました。
新しいリポジトリはこちらになります。
https://github.com/Shougo/neocomplcache-clang

さらに、manga_osyoさんのneocomplcache-clang_completeをforkしました。
Vim scriptの書き方をもっと良くする為です。

https://github.com/Shougo/neocomplcache-clang_complete

こちらは修正完了後にPull requestを投げます。

なぜ、こんなことをしたかというと幾つか理由があります。


* 本家clang_completeやclangの更新についていくことができなくなった
本家の更新は比較的早いです。私がneocomplcacheだけや、neocomplcache-clangしかプラグインを書いていないのなら、この更新についていくことが可能なんです。しかし、現状他のプラグイン開発に忙殺されているため、ついていくことができません。

* neocomplcache-clangでは非同期補完ができない

これはVimの問題とneocomplcacheの問題が複合していて単純ではないですが、本家clang_completeで使われている非同期の補完はneocomplcacheでは使えません。そのため、neocomplcache-clangでも使えません。今後Vimとneocomplcacheの更新で使えるようになる可能性はあるんですが、それには時間がかかることでしょう。

つまり、最新版のclang_complete（やclang）の機能を使ったり、非同期で補完したい場合は本家clang_completeとneocomplcache-clang_completeを併用しないといけないのです。

ただし、neocomplcache-clang_completeを使えば万能かというとそんなことはありません。

以下の問題があります。

* neocomplcache-clang_completeとclang_completeはneocomplcacheと排他的に動作している

本来、neocomplcacheとclang_completeは共存できません。なら、なぜneocomplcache-clang_completeは動作しているかというと、neocomplcacheとclang_completeを排他的に動作させているからです。これならneocomplcacheの問題もclang_completeの問題も互いに影響をすることはありません。しかし、この方法を用いるとneocomplcacheの機能がclang_completeの補完関数から使えません。なんだそんなことか、と思われるかもしれませんが、neocomplcacheの独自機能は意外と多いのです。context filetype, 補完候補の統合、ワイルドカードやfuzzy補完が使えないのは個人的にかなり困ります。

* clang_completeのVim script実装はかなりアレである

clang_completeのVim script実装はあまり綺麗なものではありません。その上、デフォルトでcompletefuncを上書きし、自前で自動補完も実装されているため、neocomplcacheと競合してしまいます。本格的に修正するには、Vim script部分がおそらく違うものになってしまうと思います。それをclang_completeでは修正していますが、変更点が巨大すぎるため、本家と追従できないという問題を抱えています。本家にPull requestを送ってもいいのですが、変更点が大きく、さらに喧嘩にならないようこちらの修正意図を*英語で*伝えるのは大変です（意訳：だれかやってください）。

将来について：

いつか、neocomplcache-clangとneocomplcache-clang_completeは統合したいですが、なかなか難しいところです。Vimとneocomplcacheの問題が解決したらそうしようと考えています。おそらく、neocomplcache-clangの実装はclang_completeのcompletefuncを安直に呼ぶことになるでしょう。