Emacsのために書いたけど、だいたいVimにも通用する気がする。GUIのエディタで通用するのかは知らない。
複数の環境で共通の設定ファイルを利用できるようにする
複数の環境、例として手元のMacBookや個人のVPS、会社の開発用のサーバーなどで個別に設定をするのは非効率です。.emacs.d
や.vim
などのディレクトリをGitなどで管理してGitHubなどにアップロードすると良いでしょう。
GitHubに公開することに抵抗があれば、Bitbucketは無料でプライベートリポジトリを作成することができます。
UNIXの設定ファイルは$HOME/.emacs.d/init.el
や$HOME/.vimrc
のようにホームディレクトリの決まった位置に置かなくてはいけないことが多いですが、実はシンボリックリングでも問題ありません。
つまり、私の場合は以下のように運用します。
cd ~/local/
git clone git@github.com:My-Account/dotfiles.git
ln -sfv $HOME/local/dotfiles/.emacs.d $HOME
ln -sfv $HOME/local/dotfiles/.vim $HOME
ln -sfv $HOME/local/dotfiles/.vimrc $HOME
ln -sfv $HOME/local/dotfiles/.zshrc $HOME
ln -sfv $HOME/local/dotfiles/.zshenv $HOME
このように固めておくことで、バージョン管理がしやすくなります。最新の内容を反映するには cd ~/.emacs.d/; git pull --rebase
だけです。
dotfilesの紹介としてさいつよのターミナル環境を構築しよう - Qiitaは非常にためになる記事ですが、なかでもdotfilesはたまごっち
の名言が光ります。
たまごっちの世話をするようにinit.el
や.vimrc
を日常的にメンテナンスしてgit push
することで、ほどよくGitHubのプロフィールページを緑に染めることが可能です。
仕事であればGitのコミットログには気を払っておくべきですが、dotfilesは完全に個人的なものなので、ブランチはmaster
一本、他人の目を気にせずgit commit -m"Update"
程度の雑なコミットで済ませておくのが継続の秘訣かなと感じてます。
私のdotfiles
のコミットログ置いておきますね…
っ https://github.com/zonuexe/dotfiles/commits/master
GitHubはSNS。すっげえ緑くなってる。はっきりわかんだね。
Qiitaのタグをフォローする / Qiitaに書く
フォローしておくといろいろ流れてくるので、ばかにしたもんじゃないですよ。
些細なことでもQiitaの記事にしておくと、他のひとは意外に知らなかったり、認識の誤りがあればコメントで指摘を受けられることもあります。
他人の設定を盗む
GitHubでdotfiles
.emacs
.vimrc
などで検索すると、山ほどあるので、読め!
とは言ってもどこから手をつけて読めば良いのかわからないので、過去の開催 - vimrc読書会や読みたいinit.elリクエストリスト - emacs-jp/reading-init.elなどに一覧があります。
もし会社にSSHでログインできる共有の開発サーバーのようなものがあれば、設定ファイルを盗み見ましょう。UNIXのファイルシステムではデフォルトのパーミッションでホームディレクトリに読み込みの権限が付与されてるのはまさにそのためです。盗むしかない。
同僚の設定には業務に役立つ知見が詰まってるかもしれないし、別に大したことは書いてないかもしれない… 1
プラグイン/拡張をパッケージ管理する
いちいち手動でインストールするのではなくパッケージマネージャーに依存するようにすることで、新しい環境でのセットアップや更新を効率化することができます。
Vimの場合はShougo/neobundle.vimが鉄板ですが、最近はjunegunn/vim-plugってのもあるらしいです。
- [Vim as IDE 第1回] NeoBundleを利用してvimプラグインを一元管理する - Qiita
- Vim - Effective NeoBundle -- autoload関数を理解しNeoBundleを使いこなすための8の方法 -- - Qiita
- NeoBundle から vim-plug に乗り換えてみた - Qiita
EmacsではVim界隈ほどパッケージマネージャーが普及してない印象があるのですが、CaskかEl-Getが良いです。詳細は2015年Emacsパッケージ事情 - Qiitaに書きました。
あたり前のようにやってることを疑ってみる
プログラミングに限らずさまざまなことについてそうですが、習慣化してることの個々について冷静に見つめてみると意外な学びがあります。具体例を挙げにくいですが、コピペして設定した変数の意味を調べてみたり、なくてはならない魔法のようなべんり拡張はどのような原理で動いてるのか探ってみたり、といったことです。
お気に入りのプラグイン/拡張の開発をストーキングしてみる
GitHubってSNSがあるんですけど、おもしろいソースコードがいっぱい載ってるから、気になったプロジェクトはwatchして、最新の開発情報を先取りしちゃおう!
ちなみに、milkypostman/melpaを購読すると最新のEmacs Lispパッケージ情報をたくさんキャッチできるので、貪欲にコードを読みたいひとはおすすめ。
通知全部読み切れなくなっても仕方ないので、ある程度で諦めて通知を捨てよう。
エディタをビルドしてみる
EmacsもVimも天からソースコードが振ってきたわけではなく、人間が書いたソースコードがあって、ソースコードは誰でも自由に読める場所に置かれてます。そして、UNIXシステムであれば、コンパイラやビルドツール、依存ライブラリを用意すれば割と容易にビルドすることができます。
自分でソースコードからビルドした実行ファイルともなれば若干の愛着も生まれるものです。一からソースコードを解読して全てを理解するのは大変なことですが、手元に置いておけば検索して実装を調査することができるので非常に便利です。
ただし、リポジトリの先端(masterの最新コミット)にはバグがあったり安定しないことも多々あるので、リリースされたバージョンを利用した方が安全です。また、依存する拡張やプラグインが最新版では期待通りに動作しない、といった事態もままあります。
プラグイン/拡張に過度に頼りすぎない
エディタのカスタマイズを始め、べんりなプラグインや拡張の探しかたを知ると、ついついあれこれとインストールしたくなります。そうすると無闇に起動時間が増えたり、副作用で拡張同士が干渉して挙動不審になるといったトラブルが起こりがちです。
そうなったときは、強い心で不要な拡張を削除するといった決断をしなければいけなくなることもあります。また、作業効率を上げるために寄与するのはべんりな拡張を探すよりも標準機能を覚えることだった、といった話もままあります。
Vimであれば実践Vim(原著:Practical Vim)は、Vimの基本的な機能を紹介する書籍として非常に定評があります。
ほかのエディタのユーザーをばかにしない
TwitterなどではVimやEmacsの名前を挙げて「宗教戦争wwwwwww」みたいなのをよく見ますが、あの、正直いって薄ら寒いので大人になりましょう2。各自、自分の手に馴染むエディタで楽しくコードを書ければそれが一番です。
ちなみに私は日本国内でVimやEmacsのユーザーコミュニティに参加してますが、そのような場に参加するのは他のエディタの良さを尊重する型ばかりです。また、EmacsやVimのミートアップにVimやEmacsのパワーユーザーが顔を見せることは珍しいことではありません。
たまには別のエディタを使ってみる
VimやEmacsに馴れ始めてきたところでなんですが、あなたの目的に最適なエディタは、ひょっとするとVimでもEmacsでもないかもしれません。つまり、AtomかもVisual Studio CodeかもBracketsかもしれません。
結果的にあなたが良いコードが書けるようになれば、他人がどう言ったって道具はなんだっていいのです。
まとめ
エディタは手段に過ぎないので、自分の手に馴染む道具を選ぶべきです。ただし、私はカスタマイズ可能で手に馴染む道具としてコーディング用のエディタとしてはEmacsを選びましたが、それ以外の用途にはAtomもVimもnanoも(節操なく)利用します。そしてEmacsの利用者が増えて多くの知見が共有されることを願ってます><
ちなみに、いままで私の会った最高のスーパーハカーはGentooでKateを愛用してました。