Skip to content

Instantly share code, notes, and snippets.

@Shougo

Shougo/Emacs2016.md

Created April 24, 2016 01:44
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Shougo/7fc95389ab6fddac7f78deb6ce42e82a to your computer and use it in GitHub Desktop.
Save Shougo/7fc95389ab6fddac7f78deb6ce42e82a to your computer and use it in GitHub Desktop.
Download ZIP
anything.el/helm.el と unite.vim を比較してみた
Raw
Emacs2016.md

anything.el/helm.el と unite.vim を比較してみた

  • anything.el や helm.el の話をします

  • Vim における anything.el 的存在である unite.vim の話をします

  • Emacs 全然分からないので、間違っているところがあったら突っ込み歓迎

  • さらにオマケもあるよ

About

  • Shougo です

  • https://github.com/Shougo

  • https://twitter.com/ShougoMatsu

  • 異文化交流にきました

  • 仕事：Vim、副業：？？？

  • Vim は環境

  • Vim プラグインを作っています(neocomplete.vim, dein.vim, unite.vim, vimfiler.vim)

  • Vim チョットダケデキル

  • Vim, neovim パッチチョットダケカク

  • 最近 neovim 用のプラグインを作っています (deoplete.nvim)

  • Emacs の拡張にも興味があります

  • Emacs しょしんしゃです。やさしくしてください

  • 最近ウインドウマネージャ i3 を導入しました。Vim を最大化するのに使っています。

anything.el の歴史(るびきち氏のブログより)

  • anything.el 初期は単一コマンドだけで複数のsourceを扱う(anything-sources に全部セットするスタイル)

  • anything.el 本体と各種sourceの anything-sources に分かれる

  • どのsourceをセットすべきなのか、ユーザーに分からなくなる

  • コマンドによるラッパーが数多く誕生する(設定済み anything と呼ばれる)

  • 単一のsourceラッパーが大量に書かれてカオスになる。複数sourceを組み合わせられる anything.el の利点が全くなくなる

http://rubikitch.com/2016/02/11/sd1503-helm/

helm.el の誕生(るびきち氏のブログより)

  • るびきち氏と Thierry 氏(helm の作者)は共同で anything.el を開発していた

  • るびきち氏は互換性を大事にするスタイルだったが、互換性を無視してドラスティックな変更を加えたい Thierry 氏が反発

  • Thierry 氏がるびきち氏より許可を得て、anything.el をリネームする

  • helm.el が誕生

http://rubikitch.com/2016/02/11/sd1503-helm/

unite.vim について

  • Vim にも anything.el 的なプラグインが欲しかったので作成

  • 魔改造を繰り返し、独自の発展を遂げる

  • これまでのプラグインにない究極の拡張性を持つ

  • 何でもできるが、設定するのは難しい。最も難しいプラグインの一つ

  • 例えるならば、Emacs でいう org-mode

https://github.com/Shougo/unite.vim/

比較: ドキュメント編

  • helm.el には公式ドキュメントがない

  • unite.vim は Vim プラグインでも有数のドキュメント量(4000 行)を誇る。それでも足らない

  • helm.el の Wiki は充実しているが、インストール、基本機能、FAQ しかカバーしていない

比較: コマンド編

  • helm.el には M-x や C-x C-f を置き換えるコマンドが定義されている

  • unite.vim にはラッパーコマンドは存在しない。自分で定義してほしいというスタンス

比較: persistent action 編

  • helm.el の persistent action は候補につき一つしか定義できない

  • unite.vim はそれぞれのアクションの定義を no_quit にすれば制限なし

  • unite.vim には候補プレビュー用の preview アクションというのもある。これは候補につき一つしか定義できない

比較: action 実行編

  • helm.el にはアクションの順番という概念がある

  • 先頭のアクションを Enter で実行、<F1> 〜 <F9> で 2 番目から 10 番目のアクションを実行する。anything 時代は C-e, C-j であった。

  • unite.vim にはアクションの順番という概念はない

  • Enter で実行できるデフォルトアクションは default_action と決まっているが、他は自由。アクションの名前で区別する。実行するアクション名はキーにバインドできる。

  • 例：preview は p で実行するプレビュー用アクション、open はファイルを開くアクション、delete は候補を削除するアクション

比較: resume 編

  • helm-resume は unite.vim の :UniteResume に近い

  • :UniteResume のほうが高機能

  • 「レジュームするか新しいバッファを開く」「レビュームしてさらにオプションを変更する」ことができる

比較: カスタマイズ編

  • helm.el は似たような設定が各 source に散らばっており複雑

  • unite.vim の場合は source 専用の設定変数を除き、設定インタフェースは各 source でほぼ共通になっている

比較: デフォルトアクション編

  • helm.el では source のデフォルトのアクションを変更するのは大変。source の属性を無理矢理変更する。実行時指定はできない。

  • unite.vim では簡単

  • unite.vim の場合は「起動時オプションで指定」「source の設定変更」「kind の設定変更」のパターンがある

比較: grep 編

  • helm-grep, helm-ag は unite-grep とほぼ同じ機能

  • ただし、unite-grep は検索結果のカラムにもジャンプできる

  • デモ？

比較: type 編

  • helm.el の type は unite.vim では kind と対応する

  • type はアクションを追加するのが難しいという問題があったが、最近は source 毎に定義される type 引数のリストにアクションを追加できるようになったらしい

http://rubikitch.com/2015/07/15/helm-add-actions-2/

比較: fuzzy match 編

  • helm.el では heml-M-x-fuzzy-match のように、source 個別に変数をセットして有効 化する必要がある。もしくは、強制的に全ての source で fuzzy match を有効化する。

  • unite.vim の場合はスマート

        call unite#custom#source(
        \ 'buffer,file_rec,file_rec/async,file_rec/git', 'matchers',
        \ ['matcher_fuzzy'])

比較: キーボードショートカット編

  • 候補をクエリでなく、キーボードで選択する機能。るびきち氏が愛用している

  • helm.el で削除されたが、ace-jump-helm-line.el をインストールすれば復活する

  • unite.vim ではクイックマッチ機能として標準搭載

http://rubikitch.com/2015/04/16/ace-jump-helm-line/

比較: 表示カスタマイズ編

  • helm.el は下方向分割が標準、ミニバッファで入力する

  • unite.vim はデフォルトで上方向分割だが、カスタマイズ可能、プロンプト位置も選択できる

比較: 候補表示編

  • helm.el は source 毎に候補を分割する

  • unite.vim の場合もデフォルトでは source 毎に分かれるが混ぜることも可能

比較: 自動リサイズ編

  • helm.el での自動リサイズは以下の通り。個別にオンオフする方法を私は知らない
        (helm-auto-resize-mode t)
  • unite.vim での自動リサイズは以下の通り。個別にオンオフできて便利
        :Unite -auto-resize

比較: 非同期編

  • helm.el では candidates-process という機能があり、プロセスを起動して候補と結びつける

  • unite.vim では async_gather_candidates() を使うと非同期になる。プロセスの生成自体は vimproc や if_python、ジョブ API を用いる。

比較: 実行編

  • カスタマイズした helm.el を実行するには専用のコマンドを定義する必要がある

  • オプションをちょっとだけ変えて試すのも大変

  • unite.vim の場合はコマンドの引数に source やオプションを指定するので楽

ここからオマケになります

helm.el のソースコード構成

  • helm.el: 本体

  • helm-config.el: キー設定とその他

  • helm-mode: helm を用いた補完

  • helm-match-plugin.el: 絞り込み検索

  • helm-help.el: ヘルプ機能

  • helm-source.el: sourceを定義する

  • helm-util.el: ユーティリティ

  • その他: 各パッケージに対するsource

counsel.el 概観

  • helm.el は機能が複雑すぎるのと、最近の互換性のない変更により徐々に支持を失い気味

  • 最近勢いのある counsel.el は ivy-mode ベースのファジーファインダー

  • 検索機能 swiper.el の機能として一緒に配布されている(個人的には独立すべきと思う)

  • 2015 年開発開始！

  • 単一sourceにのみ対応

  • プロンプトはミニバッファではなく、バッファの先頭に現れる(unite.vim に似た仕様)

http://rubikitch.com/2015/03/18/swiper/ http://oremacs.com/2015/04/09/counsel-completion/

unite.vim の欠点

  • unite.vim の設計思想は「anything.el をも越える究極の柔軟性」である。それは実現することができたと考えている

  • unite.vim には Vim script ベースで実装していることによるパフォーマンスの問題がある

  • Vim script は Python の数倍遅いことで有名

  • Google では "unite.vim slow" が suggest される屈辱

  • Ctrlp.vim はこの問題を機能を制限することで解決している

  • unite.vim は実装がカオス。特に UI 回りのバグ修正が難しい

denite.nvim について

  • neovim 専用(将来的には Vim にも移植予定)

  • 完全に非同期で動作

  • Python3 で実装

  • コアと UI の分離

  • 絶賛実装中

  • VimConf 2016 までには何とか……

https://github.com/Shougo/denite.nvim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment