2012年9月2日日曜日

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: 多数のバグ修正

いつもの。

2012年5月27日日曜日

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さんから「鋼の心臓を持っている
」認定を受けました。

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

2012年3月18日日曜日

「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は設定が複雑だし、慣れるのに時間がかかるため、初心者にはオススメできません……。

2012年2月9日木曜日

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とすることで以前の動作に戻すことができます。
ただし、これを設定すると既存の補完関数と互換性がとれなくなるため、作者としてこの設定を推奨する訳ではありません。

2012年1月2日月曜日

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_completeneocomplcache-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を安直に呼ぶことになるでしょう。

2011年12月15日木曜日

二画面ファイラーはなぜ便利なのか


syohexさんのTweet(リンク)を見て、二画面ファイラーの利点について考えてみました。
二画面ファイラーには次のような利点があります。

1:同じディレクトリに対して移動・コピーするのが楽
2:コピー元・コピー先のディレクトリの中身が分かる

個人的には2:の利点が大きいと思います。というのは、シェルや一画面ファイラーで
コピー・移動するときは書き込むディレクトリの中身が分からないのでコピー先のディレクトリをミスするかもしれません。
しかし、二画面ファイラーではまずミスをすることはありません。
書き込みの完了も、移動先が更新されているのが目で見て分かります。
コピー先のディレクトリが表示される安心感は、一度使ってみないと分からないでしょう。
ちなみに、私は一画面でコピーするときはいつもドキドキします。

GUIのファイラー(Explorer等)でファイルをコピーするときのことを考えます。
一つのファイラーでコピーするファイルを選択し、もう一つのファイラーにドラッグドロップするのが二画面ファイラーなのです。
とはいえ、いちいちコピー先に移動するのは面倒であることも事実です。
そのため、二画面ファイラーでは自分の窓を他方の窓に合わせたり、他方の窓を自分の窓に合わせたりすることができます。
コピー元とコピー先が近い場合には簡略化できます。

さらに、コピー先のディレクトリ名に日本語が含まれる場合、シェルや一画面ファイラーではコピー先の指定が大変です。
二画面ファイラーではそういうときでも楽にディレクトリを指定することができます。

Firefox Hacks Rebootedレビュー


ようやく一通り読み終えました。この本がもっと売れてほしいと考えているため、簡単なレビューをします。

日本からこういうマニアックな(失礼)、本が出るのは非常に喜ばしいです。
外国でもなかなか出ない種類の本であるだけに、日本はまだまだ捨てたものではないな、と思わせてくれます。
この本はFirefoxのモダンな拡張機能の作り方を解説した本なので、Firefoxの一般ユーザが読むには難解です。
コード量も多いので、読み進めていくにはJavaScriptの知識が必要になるでしょう。
ただし、最近のFirefoxで変更された機能やHTML5などのWeb標準技術についても解説されているため、Web開発者なら読む価値があると思います。一見真面目な本のようで、所々挿入されているネタには吹きました。
きゅ○べぇネタや、台湾マイクロソフトの始まりすぎているキャラクターなど……。
JSDeferedには40ページ以上を割いていて、かなり力を入れて解説していると感じました。
JavaScriptの並列処理をマスターしたい人は、ここだけでも読む価値はありそうです。
実を言うと自分はKeysnailとVimperatorの解説を目当てで、この本を購入しました。
ページ数としてはそんなに多くなかったのですが、概要を押さえることはできました。

総評:
思っていたとおり、なかなかレベルの高い本でした。
でも、Firefoxのことがよく分かったので買ってよかったと思います。
自分は現在Firefoxを使っていないのですが、面白そうな機能があることが分かったため、今度試しに使ってみてもよいかなと思っています。