ベターVimとしてAtomを使う
この記事はATOM-editor Advent Carendar 2015の15日目の記事です。
2016/03/01 追記
vim-mode-plus, vim風キーマッピングの発見により色々追記しました。
はじめに
どうも、Vimの方からやってきました。
様々なエディタやIDEにVimプラグインがあることから分かるように、どんな環境に移ろうともVimと共に生きるVim愛好者は世界中にたくさんいるようです。
自分もそのうちの一人でメインエディタはVimを使い、IDEを使うときもVimプラグインが手放せなかったのですが、さすがに2015年にもなったし流行りのエディタも試してみたいということで今年からAtomに入門してみました。
Atomにも例に漏れずVimプラグインがあるので初日からVim化に挑戦するも、色々と足りない機能に納得できずSublimeのときのように諦めかけていたのですが、パッケージを色々探したところ大体自分が満足するところまでVim化することができました。今回はそのときに見つけたパッケージを紹介したいと思います。
*ほとんどのパッケージのページにgifアニメがありますので、ぜひリンクを覗いてみてください。
自分の紹介より見たほうが分かりやすいかと思います。
Vim標準機能を実現するパッケージ
vim-mode
2016/03/01 追記
vim-modeから色々機能が拡張されているvim-mode-plusに乗り換えました
まずはこれを入れないと始まらないです。
機能 | キー |
---|---|
カーソル移動 | h, j, k, l, gg, G, ctrl+j, ctrl+k |
インサートモード | i, I, o, O |
ビジュアルモード | v, V |
ヤンク | y, yy, yaw, yiw |
削除 | d, dd, daw, diw(削除しつつinsertモードにする'c'も使用可能) |
ペースト | p, P |
undo/redo | u, R |
検索 | /, * (検索後のn, Nも可能) |
Paneの移動 | ctrl+h,j,k,l |
数値のインクリメント/デクリメント | ctrl+a, ctrl+x |
繰り返し | .(コロン) |
実現できている機能一覧ページが見つからなかったので、どこまで本家Vimの挙動をカバーできているのか正確には分かりませんがこのあたりの基本操作は抑えているようです。
vimで検索結果をハイライトさせるhlsearch機能が無いことが個人的には非常に惜しいのですが、Pull requestを見る限り精力的に開発が続けられているのでそのうち実現されるでしょう。
ex-mode
2016/03/01 追記
vim-modeからvim-mode-plusに乗り換え、ex-modeが使えなくなったので代わりにキーマッピングを使う方法を追記しました
vimという名前が付いていないので最初は気が付きませんでした。vimのexモードを実現するパッケージです。
‘:'を入力することで本家Vimと同じように:w, :wq, :q, :sp, :vspなどが使えます。
vimで作業(特にコードリーディング)するときはガンガン画面分割をしてカーソル移動させまくっているので、ex-modeを入れることでatomでも同じことができるのが感動的でした。
ちなみに:s, :%sによる置換も一応可能なのですが、自分で試したところ以下の機能が実装されていないため残念ながら実用的とは言い難いです。
- 検索結果を使った省略記法(fooを検索後にbarに置換したい場合、本家vimであれば:s//bar/で置換できる)
- カーソル上の単語をテキストボックスにペースト(本家vimでのctrl+r, w)
- 置換オプションのg, c
- ビジュアルモードでの選択範囲限定での置換
vim-mode-visual-block
2016/03/01 追記
vim-mode-plusには元々ビジュアルモードが組み込まれているので自分は不要になりました。
本家vimでの矩形ビジュアルモードを実現するパッケージ。神。
矩形モード選択からの'I'や'A'でinsertモードに移行した一括編集も実現してます
cursor-history
vim-mode-visual-blockと同じt9mdさんによる本家vimのctrl-oを実現するパッケージ。神。
Highlight Selected
元々はSublimeTextで単語をダブルクリックすると同じ単語を全てハイライトしてくれるという機能のコピーのようですが、 vim-modeでは現状検索結果のハイライトができないのでその代わりとして使っています。
sort-lines
選択した範囲の行をソートしてくれます。
たまにお世話になるvimの:sortと同じですね。
有名なVimプラグインの代替
linter系
lintでパッケージ検索すると各言語用のlinter-**がたくさん見つかります。
syntasticは非同期にチェックできなかったので巨大なファイルだと保存時に固まるという問題がありましたが、atomのlinterは非同期にチェックが走っているので非常に快適です。
autocomplete系
Vimだと: neocomplcache, neocomplete
linter同様、autocompleteで検索すると各言語用のパッケージが色々見つかります。
autocomplete-pathと自分が使う言語用のものをインストールしてしまえば入力補完で困ることはほぼ無いと思います。
status-bar系
Vimだと: powerlineあたり
(ちなみに自分はlightline.vimを愛用してました)
vimにはステータスバーにgitブランチ情報や文字コードを表示させるpowerline系のプラグインが色々ありましたが、atomではそのあたりの情報はデフォルトでステータスバーに表示されてます。
clip-history
vimだと: yankringあたり (ちなみに自分はyankround.vimを愛用してました)
いわゆるクリップボード拡張系のパッケージ。
vimモードに関係なくatomのパッケージに色々ありますが貼り付けるときにいちいち候補を選ぶUIが余計で、yankround.vimでctrl+pだけで済んでいた操作性に比べるとイマイチっぽかったです。
clip-historyはyankround.vimをそのままatomに移植してきたという感じで非常に使いやすいです。
ちなみに作者はvim-mode-visual-block, cursol-historyと同じt9mdさんです。いつもお世話になっております。
script
vimだと: vim-quickrun
開いているスクリプトを実行して、実行結果をatomに表示してくれます。 試行錯誤しながら書いているときに非常に便利。
vim-modeでのキーマッピング
vim-modeを入れるとatomのキーマッピング設定にvimでのnormalモードや、insertモード中かの条件分けができます。
'atom-text-editor.vim-mode.normal-mode': 'ctrl-i': 'cursor-history:next' 'ctrl-o': 'cursor-history:prev' 'atom-text-editor.vim-mode:not(.insert-mode)': 'ctrl-p': 'clip-history:paste' 'ctrl-P': 'clip-history:paste-last' 'ctrl-n': 'clip-history:paste-newer'
上は自分のkeymap.csonの一部です。
カーソル移動系のcursor-historyはnormalモード、ペースト拡張系のclip-historyはinsertモード以外、というように各モードごとにキーマッピングが可能になっています。
今後別のパッケージをマッピングしたいということになってもコンフリクトを減らせそうですね。
おわりに
ここまで紹介したパッケージを導入したことでVimで実現できていたことをAtomでも実現できるようになり、今では快適なVim生活をAtom上でおくれています。
じゃあVimでよくない?という意見をもらうことが多いのですが、何度かvimscriptにもチャレンジしたもののvimscriptの基本的な挙動について自分が知りたい情報を見つけるのがしんどすぎるのと、業務用に書いた簡単なプラグインを数ヶ月後に自分で見返した際にvimscriptで何が書いてあるのかさっぱり分からなかった(自分が書いたにも関わらず)のがキッカケで本格的にAtomに移行を始めようと思いました。
Atomでのパッケージ作成は勉強し始めたばかりですが、それなりに慣れ親しんだCoffeeScriptで書けるのと、そもそもAtomのほとんどの基本機能がパッケージで提供されていて参考にできるサンプルが多いのでVimを本格的にカスタマイズするよりは障壁がだいぶ低い感じです。
2016年もベターVimとしてAtomを使っていこうと思います。
2016/03/01 追記
記事を書いてからさらにベターVIm化を進めることができたので紹介します
vim-mode-plus
t9mdさんによるvim-modeの拡張版。 詳しい説明は22日目のAdventCalendarにご本人による紹介記事があります。 どのような機能が追加されているのかは、公式のgifアニメを見るのが一番理解が早いと思います。 vim-modeとはパッケージ名が変わっているのでキーマップを変える必要がありますが、これも公式でサンプルが用意されているので必要なところを自分好みに書き換えるだけで乗り換えられると思います。
個人的には/
検索の強化が一番感動しました。vim-modeでも/
による検索はできましたが、インクリメントサーチとハイライトが効かなかったので、本家Vimに比べると片手落ち感が否めませんでした。
vim-mode-plusはこの点が改善されていて、この機能だけでも乗り換える価値がありました。
キーマッピングによるex-modeの置き換え
自分はこのキーマッピングを追加することでex-modeが不要になりました。
# emulate vim ex-mode # https://github.com/atom/vim-mode/issues/50 '.editor.vim-mode-plus:not(.insert-mode)': ': w enter': 'core:save' ': q enter': 'core:close' ': s p enter': 'pane:split-down' ': v s p enter': 'pane:split-right' 'g c c': 'editor:toggle-line-comments' # emulate tomtom/tcooment_vim
vim-mode-plusに乗り換えたことでex-modeと連携できなくなり、色々探していたらvim-modeのissueからこのコメントを発見しました。
キーマッピングで:w
を再現するというもので、見つけた時に「その発想は無かった!」と感激しました。
置換だけはやはり本家Vimの再現はできなかったのですが、もうAtomの元々の置換機能でいいかなという感じになってきました。
2016/02時点の自分の設定
自分のdotfilesの.atomディレクトリにキーマップもパッケージ一覧も置いてあるので、よければ参考にしてみてください。
Python3.5の型ヒントをとりあえず試す
Python3.5がリリースされましたね。
Python書くのはほぼ1年ぶりでしたが、噂の型ヒントがついに3.5で導入されたようなので早速試してみました。
型ヒントについてこちらに素晴らしいPEPの翻訳記事があり、見て頂けると分かりますがPython3.5単独ではまだ型チェックはできません。 標準モジュールに入ったのは型ヒントを与えるためのtypingモジュールであり、そのヒントを基にチェック型チェックを行えるのは(現状では)mypyというサードパーティのモジュールになります。
mypy
Pythonの型ヒントは今のところ実行時に型チェックをしたりJITのためにするためのものではなく、mypyも静的に型チェックを行うLintツールです。
ちなみにmypyをインストールするにはmypy-langという名前でpip installする必要があるので注意。pip install mypy
でインストールされるモジュールは全然別物のようです(紛らわしい・・・)
最近エディタとして使っているatomにはまだプラグインが存在していないのか、mypyを使うLinterは見つけられませんでした。
vimプラグインのsyntasticを見るとmypy用の設定があるように見えるのですが、なぜか自分の環境では動かなかったので一旦エディタから使うことを諦めました。
とりあえずgit hooksでmypyを試す
エディタのプラグインは諦めたので、代わりにgit hookに仕込んで最低限の自動チェックを入れてみました。
CIツールを用意しなくても普通にgitでコードを管理していれば絶対に実行されるので、mypyに限らずcommitフックでチェックするのはオススメです。
# .git/hooks/pre-commit STATUS=0 for file in `git diff HEAD --name-only | grep -E '.py$'`; do mypy $file || STATUS=255 done exit $STATUS
所感
個人の小さなプロジェクト(クラスが1-2個程度)で試して気になった点
- Atomのシンタックスハイライトが関数アノテーションを入れると壊れるのが辛い
- Vimはちゃんとハイライトしてくれた
- 関数アノテーションは見た目的にはさほど問題無いが、変数宣言の行末に
# type: int
とかが並ぶと見た目がうっとおしい - mypyがimport文で
error: No module named **
とめちゃ怒るのがウザい- とりあえず
# type: ignore
を付けることでエラーを抑制できる - 標準モジュールはスタブを用意すれば問題ないらしいが、サードパーティモジュールは今後もignore書く必要があるのだろうか・・・
- とりあえず
個人プロジェクト程度のコード量だと全体を把握できているので、自作クラスにわざわざ型を付けるメリットはあまりなさそうかなという感じでした。
個人規模のものはサードパーティモジュールに依存する部分が広くなるため、有名どころのモジュールがいかに対応するかが普及には重要そう。
逆に企業のコードは自作モジュールに依存する部分が広いと思いますので、自前で型情報を付ける必要があるコード量が多くなる。
という事情を考えると、型ヒントを書くのが一般的になるとしても結構時間がかかりそうですね。
(そういう未来が来ない可能性の方が高そう)
参考
herokuにデプロイするときでもgruntしたい!(+rubyサーバー)
JSの勉強のためにタイトルのような構成のwebアプリをherokuにデプロイしようとしたところ、主にjsのライブラリ管理やcoffeeのコンパイルなどで苦労したのでメモ。
rubyだとjs周りも面倒見てくれるRails関係のgemが色々あるみたいですが、jsは独立して管理した方がいいという風潮を最近感じているのでgemには一切依存しない形にしてみました。
(試していませんがサーバー側をPythonやPerlに置き換えても問題ないはず)
構成
サーバー: ruby(sinatra)
クライアント: coffee-script(gruntでjsにコンパイル)
jsライブラリ: BoostrapとかjQueryなど(bowerでインストール)
サーバー側
サーバー側でやることは何もありません。
js周りの面倒を見てくれるgemを一切入れないので、sinatraで簡単なrubyサーバーをherokuにプッシュするために最低限必要なGemfileとProcfileだけあればよいです。
Gemfile
ruby "2.1.2" gem "sinatra" gem 'haml' group :development do gem 'foreman' gem 'heroku' end
Procfile
本当はunicornとか使うべきなのだろうけど、sinatraのデフォルトでもとりあえず動く。
web: bundle exec ruby app.rb -p $PORT
クライアント側
今どきのjsはbowerでライブラリを管理するらしいので、BootstrapやjQueryといったライブラリをbower install --save
でインストールします。
--saveを付けて必要なライブラリをbower.jsonで管理することで、外部ライブラリをgitで管理せずともherokuにデプロイしたときに向こう側でインストールできるようにしておきます。
coffeeもコンパイルするたびにgitにコミットするのは大変なので、コンパイルされたjsはgitに追加せず元のcoffeeだけgitで管理します。
問題点
という方針で開発を進めていたのですが、いざherokuへのデプロイという段階で壁にぶつかってしまいました。
herokuのbuildpackは単一言語しか動かない
herokuのbuildpackは基本的に1つのプログラミング言語しか動かないので、この構成ではrubyは動くがnodeが動かずbowerでjsライブラリのインストールができませんでした・・・
この問題を解決するheroku-buildpack-ruby-bowerというサードパーティのbuildpackもあるようですが、今後もメンテされるかが不安なので公式のbuildpackで解決する方法を探してみました。
解決策
mulit_buildpack
で、見つけたのがこのmulti_buildpack。
これを使うと.buildpackに定義した複数のbuildpackを1つのインスタンスに入れられるので、rubyとnode.jsのbuildpackを両方とも入れてしまうことでbowerも使えるようになります。
multi_buildpackを使う場合には、herokuアプリを最初に作成するheroku createで使用するbuildpackの指定をmulti_buildpackにする必要があります。
heroku create -b https://github.com/heroku/heroku-buildpack-multi.git your-app
次に、以下のように公式のrubyとnodejsのbuildpackを定義した.buildpacksというファイルを作ってからherokuにデプロイをすることで、めでたくrubyとnodejsの両方が動くインスタンスになります。
.buildpacks
https://github.com/heroku/heroku-buildpack-nodejs https://github.com/heroku/heroku-buildpack-ruby
ちなみにこの記事を書く前にはこの方法を各所で見みかけたのですが、何気にheroku公式ドキュメントを見たらheroku buildpacks:setとheroku buildpacks:addというコマンドを使うことでも同じことができるみたいです。
お好きな方法でどうぞ。
https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app
JSライブラリのインストールとcoffeeからのコンパイル
gruntやbowerの使い方をググるとだいたいnpm install -g
でインストールしましょうと書かれていることが多い気がしますが、 この方法では手元のPCでgrunt, bowerが使えるようになるのですがheroku側にはインストールされないため、このままherokuにデプロイしても上手くいきません。
解決するにはpackage.jsonをこんな感じに書きます。
{ "name": "MarkdownServer", "version": "0.1.0", "dependencies": { "bower": "^1.4.1", "grunt": "^0.4.5", "grunt-cli": "^0.1.13", "grunt-contrib-coffee": "^0.13.0" }, "devDependencies": { "grunt-contrib-connect": "^0.10.1", "grunt-contrib-watch": "^0.6.1" }, "scripts": { "postinstall": "bower install && grunt build" } }
まずはdependenciesにbowerとgruntを追加してbowerとgruntを使えるようにして、postinstallにbower install && grunt build
を書いておくことでbowerとgruntのインストール後にbowerとgruntを起動させます。
herokuにpushすると自動的にnpm install
を実行してくれるので、
npm install bower install grunt build (Gruntfile.jsにbuildでcoffeeのコンパイルなどが行われるように自分で定義しておく)
の順番にコマンドが実行され、無事に依存jsライブラリののインストールとcoffeeのコンパイルが行われるようになります。
結論
- multibuildbackを使う
- package.jsonにbower, gruntのインストールとpostinstallでの実行を記述しておく。
ローカルのPCで動いている状態からherokuデプロイ用の設定を書くのはなかなか面倒でしたが、herokuへのデプロイは特別なコマンドを使っていないので、
herokuにデプロイできるようにする = どの環境でもコマンド一発叩けばインストールできる
ということになり結果的に非常にポータブルになりました。
いざとなればVPSなどへのお引越しも簡単にできるようになるので、git clone後にコマンド一発でインストールできるように設定しておくことは大事。
ちなみに執筆当時に書いてたWebアプリでここまでの設定を書き終えたのがこちらです。 設定のサンプルにどうぞ https://github.com/Kesin11/MarkdownServer/tree/a389c477f95cabe0624e77d193b56b0237603a1f
参考
今年の自分のvimrcを振り返る(2014)
長らくブログを放置していて、気がつけばAdventCalendarの季節も通りすぎて2015年になってしまいました。
去年は自分にとってVimの進歩があった年だったので、git log .vimrc
の中からTOP10をまとめてみました。
1位 実践Vim
- 作者: DrewNeil,新丈径
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/01/28
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
今まで手に取らずに長いこと損をしていました...っ!
.による繰り返し、検索・置換のテクニック、マクロ機能などの小技が盛り沢山だっただけではなく、知らなかった設定も色々ありました。
中でも便利になった設定が以下の3つ
incsearch
set incsearch
今どきのGUIエディタのように/の検索中にマッチした部分にオートスクロールしてくれます。
Ctrl+pで履歴呼び出しにフィルタリング
cnoremap <C-p> <Up> cnoremap <C-n> <Down>
コマンド履歴の呼び出しを↑↓で行うと入力している文字で自動的にフィルタリングが行われますが、Ctrl+p, Ctrl+nによる履歴の呼び出しではフィルタリングが行われません。
ホームポジションから手を動かしたくないので、良いところどりをするためにCtrl+p, Ctrl+nを↑↓に割り当てます。
wildmenu
Vimのコマンドモードのtab補完はクソすぎると思っていたのですが、ちゃんと設定すれば補完メニューも出せるし、どこまで補完するのかも設定できます。
set wildmenu set wildmode=longest:full "コマンドモードの補完タイプ
自分の設定だと"Neo"まで入力してtabで補完するとこんな感じに表示されます。
続きを読む
PyConJP 2014に参加してきました
今年も9/13,14に行われたPyConJP 2014に参加してきました!去年に引き続き、2回目の参加です。
今年の会場は去年に比べて交通は少し不便になってしまいましたが(特に東京テレポート駅からは遠い)、会場の中はホールや教室とドリンクバーが離れておらず、良い意味でこじんまりとした場所でした。
今年はチケット代に二日間のランチ + 何と懇親会のパーティ付きでした。ありがとうございます!
特に1日目のランチはテーマごとの席が用意されていて、初対面の人とでも会話しやすくてありがたかったです。
実は最近Pythonを使っていないので去年ほどのワクワク感は無くなってしまったのですが、いくつか面白かった講演の感想などを書きたいと思います。
パッケージングの今
去年に引き続き、Pythonのパッケージングライブラリがどうなってきているのか、という話。
実は今までパッケージをPyPIに登録するという経験が無かったので、Pythonのリハビリも兼ねて作った小さなライブラリをPyConJP会場からPyPIに登録したばかりでタイムリーな話題でした*1。
setup.pyにはよく分かっていないままにsetuptoolsを使ったのですが、とりあえず今の本流らしくて安心しました。
wheelは去年聞いたときはピンと来なかったのですが、先日Macでnumpyをpip installしたときにコンパイルが走らずにインストールが完了したときに感動しました。
numpyのようにC言語や他のライブラリとリンクさせる巨大なライブラリではインストールだけで何十分もかかっていたのですが(しかも依存ライブラリとか設定がしっかりしてないとコンパイルエラーで落ちる)、それも過去の話になりそうです。*2
Pythonはおそらく標準ライブラリが充実しているために依存関係が少なくて外部ライブラリのインストールが早い、ということを別言語に移行して再発見したところだったので、wheelの導入でさらにインストールが早くなるのは素晴らしいと思います。
正規表現リテラルは必要なのか
このセッション一番の学びは、re.matchやre.searchは内部でコンパイルした正規表現をキャッシュしているということでした。re.compileが不要かどうかは計測しないと分からないところですが。
個人的には、正規表現リテラルはやはり便利だと思います。文字列操作の関数の方が分かりやすいという意見も分かるのですが、Linuxでsedとかgrepを使いこなすようになると、文字列操作をするときは自然と正規表現を考えるようになるので文字列操作関数はいつの日か使わなくなってしまいました。そうなるとPythonだけre.search()とか使わなきゃいけないのが単純にめんどくさいんですよね。
Perlを使い始めた時はPythonに比べて色々めんどくさいなーと思いながら勉強していましたが、Perlの正規表現に関しては最初に見たときに感動しました。
やっぱりリテラルがあるとカジュアルに正規表現を使っていけるんですよね。まぁ、カジュアルに使いすぎて後々苦しめられることがあるのも事実なのですが・・・。
1日目 Keynote Kenneth Reitzさん
順番的には一番最初の講演なのですが、一番おもしろい話だったので最後に持ってきました。
CH01 Opening~Keynote: Kenneth Reitz - YouTube
RequestsライブラリやHerokuの話しかと予想していましたが、Python2と3の話でした。
自分の記憶ではPython3は3.2ぐらいから安定してきたと言われていて、Djangoやnumpyが3に対応したと聞いていたのでそろそろ3に本格移行が始まっているのかな、と思っていましたが会場のアンケートでは2の使用者がまだまだ多くいらっしゃるようでした。
その後のスライドで2014年1月に2週間にPyPIからPython2と3でどれだけパッケージがダウンロードされたかの統計が示されていたのですが、圧倒的に2が多く(動画の45分あたり) 、コア開発者は3の開発をどんどん続けているのにコミュニティが2に留まり続けているので断絶が起きてしまっているらしいです。
このセッションは質疑応答の方が盛り上がって、Python界隈からするとかなりギリギリの話もあったかと思います。
個人的に印象深かったのは以下の3点
- Kennethさんは個人的な意見としながらも3にメリットは無いと発言
- Pythonは安定した言語だったので、Rubyと違って新バージョンへ移行する文化が無かった
- 現時点でコミュニティが出している回答は2の維持
3にメリットが感じられないというのは個人的に同感で、3に移行するメリットで有名なのは
- Unicode回りが改善
- printとかtry-exceptのようなイマイチだった構文の改善
- 標準ライブラリが整理された
ぐらいだと思います。既に2.7は今後開発されないと宣言されていますが、苦労して今までのコードを書き換えて、正しく動作することを確認するコストと比較すると、現時点で得られるメリットが少ないと言わざるを得ないと思います。
各ライブラリの対応状況を見ると、主要なライブラリは大体3に対応してきているので、Python3に移行しない最大の理由である「ライブラリが対応していないから」というある意味言い訳も通用しなくなっていると思います。それでもユーザーが移行しないとなると、質疑中でPerl5とPerl6の話も出ましたが、Pythonでも同様にPython3の成果をPython2にバックポートし続けて別々の言語として発展し続ける・・・という未来もありえるのかもしれません。
自分としてはPythonを触る機会が減ってきてしまってほとんど新規ユーザーと同じ状態なので、これからはとりあえずPython3を使ってみようと思います。