2012年3月8日木曜日

sonictemplate-vim の unite souce を書いてみた

- Big Sky

上記エントリで、 mattn さんが作成・公開されたテンプレートプラグインで用いるテンプレートを、リスト表示して適用する unite source を書いてみました。

plugin自体は導入していたんですが、使いこなせていなかったため、勉強も兼ねて。

便利な差分を書いた!という感じのことをした場合、
こういう独自記事を書くんじゃなくて、pull リクエストを送って評価してもらうのが筋なんでしょうか…
そうするべきという感じであればこのエントリは削除して pull リクエストを送ってみます。

取り急ぎ、非常に恐れ多いのですが、晒してみます。
ざっと探した感じでは類似の物は無かったと思うのですが、既にどこかにあったらすみません。。

- forkして手を加えたリポジトリ
--  https://github.com/kmnk/sonictemplate-vim

- 使い方(ドキュメント追記差分)
-- https://github.com/kmnk/sonictemplate-vim/commit/0aebcc039d55cb2b2fdf43efbe1b5dd118dd3333

unite source に加えて、template を格納するディレクトリを複数指定できるように、少し改造しています。

動作例 :
hoge.pl を新規に開いて base テンプレートを適用した後、 :Unite sonictemplate を実行

オリジナルのpluginに補完関数が定義されているため、template 名の補完は効くようになっているのですが、自分の記憶領域の容量が非常に少ないので、一覧できるととても助かる気がします。 
一段階挟むことになるので、即時性は失われますが、 -input と -immediately を組み合わせてmapを工夫すればそれも克服できる…はず…

ついでに vim script 用のtemplateもちょっと書いてみました。

https://github.com/kmnk/config/tree/master/vim/dot.vim/templates/vim

vim script のtemplateはpull リクエストしても良いかも…と調子に乗りかけています。

以上です。

酷評をお待ちしておりますmm

2012年2月26日日曜日

git status と git branch ができる unite の source 書いた

書きました。

https://github.com/kmnk/vim-unite-giti

すでに有りそうな気もするんですが、今のところ知らないのと、

http://kmnk.blogspot.com/2011/02/unitesvn-statussvn-diffsource.html

で書くといって既に一年経っているのとで自分で書いてみました。

まだ仕事でがっつり使っていないので、バグや動作不全などあるかもしれません。

昔作った svn と違って何故か vim-unite-git じゃなくて giti なのは、日和っただけで深い意味は無いです。

インストール方法は割愛します。unite.vim 使っている方なら余裕なはずという想定で…

作ったsourceの名前は以下。

  • giti/status
  • giti/branch
追記(02/29): READMEには追加しているんですが、sourceをいくつか追加しました。以後は README.markdown を参照してください。
  • giti
  • giti/log
  • giti/config
 追記ここまで(02/29)

それぞれ、独自 kind を定義していて、以下のactionを持っています。

giti/status

  • add
    $ git add $FILES
  • rm_cached
    $ git rm --cached -- $FILES
  • reset
    $ git reset HEAD $FILES
  • commit
    $ git commit $FILES
  • amend ←動作が怪しい
    $ git commit --amend $FILES
  • checkout
    $ git checkout -- $FILES
  • diff
    $ git diff $FILES
  • diff_cached
    $ git diff --cached $FILES

git/branch
  • run
    $ git checkout $BRANCH_NAME or git checkout -b $NEW_BRANCH_NAME
  • delete
    $ git branch -d $BRANCH_NAME

その他、以下の関数を用意しています。key map などして使えるかもしれないです。

  • giti#branch#delete_force(branch)
    $ git branch -D $BRANCH_NAME
  • giti#commit#dry_run(files)
    $ git commit --dry-run $FILES
  • giti#push#run()
    $ git push
  • giti#push#run(repository, refspec)
    repository と refspec を指定して push
  • giti#push#expressly()
    repository と refspec の入力を対話的にやる
追記(02/26): よくよく考えたら、関数提供しても command  にしないと CommandLine で使いにくいことに気づいたので、いくつか command を追加しました。
  • GitiDiff
  • GitiDiff $FILE1 $FILE2 ...
  • GitiDiffCached
  • GitiDiffCached $FILE1 $FILE2 ...
  • GitiPush
  • GitiPush $REPOSITORY $REFSPEC
  • GitiPushExpressly
下記のような感じに設定しています。

if globpath(&rtp, 'plugin/giti.vim') != ''
  nnoremap <expr> <silent> <Space>gD ':<C-u>GitiDiff ' . expand('%:p') . '<CR>'
  nnoremap <expr> <silent> <Space>gd ':<C-u>GitiDiffCached ' . expand('%:p') .  '<CR>'
  nnoremap <silent> <Space>gp :<C-u>GitiPush<CR>
  nnoremap <silent> <Space>gP :<C-u>GitiPush
endif
追記ここまで(02/26)



以下、例によって簡単な動作デモ


:Unite giti/status




何もないときでも、commit --amend などは実行したいので、常に候補としてdummyを表示しています。


action はこんな感じに。


file を編集して保存したので、差分が出ます。新ファイルなので Untracked


add


IndexStatus が Added になります。


更に編集すると、 WorkStatus が変わるので


また add


こんな感じで繰り返していきます。


間違えて編集したとき(まだ add してないとき(WorkStatus が Modified))は、


checkout で戻す


戻りました。add 済みであれば reset を使います(reset HEADが実行されます)。


しばらく作業したら commit したいファイルを選択して


commit


コメントを編集して ZZ


commit できました


新規に add したけど、やっぱり要らなくなったものは


rm_cached


Untrackedにもどります。


commit しちゃったけど要らなくなったものは、


file kind に追加されている git_rm action を実行


Deleted になります


giti/branch も入ってますが、しっかり動作確認できていないです。多分動く…

かっとなって作ったため、まだ仕事で使っておらず、動作が不安定な箇所もあると思います。バグや要望等ありましたらお知らせ下さい。
一応、そのうちやりたいなということは、README の TO DO に書いていますが、実装予定は未定です。。

Vim script on Vim script もドキュメントしっかり書いた方が良いのかな…

2012年1月9日月曜日

2012年の抱負的な何かのつづき

英語をそれなりに読み書きできるようになる
  • 1月中はなんとなく検討しておく
  • 2月中に簡単な何かをピックアップして試してみる
  • 3月中に英会話に通うか決めて4月頭に決行
 一ヶ月に一冊文学本を読む
  • 2月中に積んであるのと読みたいのを洗い出す
  • 2月から読んでいく


Vim script 5本は公開する
  • 1月中は何か不便に思ったりしたものを片端からメモる
  • 2月は上記を実行しつつ、何か書いてみる

他人の OpenSource の何かにパッチを送る
  • 1、2月中は言語とか興味の方向とか検討
  • 3月にターゲットを決めてソースを読む
  • 4月も読みつつ使う


自社サービスをちゃんと使う
  • タッチアプリを作る
  • 2月中にテストアプリを再作成
  • 3月中に簡単なアプリを作る


運動をする
  • 2月中に何やるか決める
  • ランニングか筋トレか水泳か?


色々積まない
  • 積まない物
    • ゲーム
    • 技術本
    • 文学本
    • 食器洗い
    • 掃除


身の回りを綺麗に保つ
  • 2月第一週で再度大掃除
  • それ以降は毎日どこか綺麗にする


何かで3回くらいは人の前に立つ
  • 4月までに色々挑戦する。目標以外に。
  • 5月以降でネタと挑戦場所を検討していく

2012年1月8日日曜日

2012年の抱負的な何か

年も明けたので。


とりあえず達成したい目標を羅列


- 英語をそれなりに読み書きできるようになる
- 一ヶ月に一冊文学本を読む
- Vim script 5本は公開する
- 他人の OpenSource の何かにパッチ送る
- 自社サービスをちゃんと使う
- 運動をする
- 色々と積まない
- 身の回りを綺麗に保つ
- 何かで3回くらいは人の前に立つ

後やること
- 具体的な小目標を、これくらいできないと人としてダメだろ適なレベル感で決める
- 締め切りを切ってスケジュール立てする
- 最終的に日記にする
- を1/9中にやる

以上を最初の目標にする。

2011年11月19日土曜日

ujihisa.vim#2 に行ってきました

愛を語るには長い道のりが必要であり、
まずは友達から始め、地道に歩まなければならない。

ということを学んだ勉強会でした。

Fin.

以下余談

多々勉強になったのですが、Kaoriyaさんの "Vimのソースコードをdisってみよう" で、とりあ
えず動くものを作ってユーザーを獲得して、そのユーザーを保持し続けることの重要性だというのを多々感じました。
これはツールだけじゃなくて、何にでも言えることだなぁと。

後ほど直で話を伺って、生きるモチベーションを頂きました。
きっとこんな自分でも、何か頑張れるんじゃないか・・・むりかな・・いや・・


その後、ちょっと前のエントリで出してみた物を、先輩に使っていただいたら、いきなりバグっていたりと、作ったら広めて使ってもらってdisってもらわないと何も始まらないなと反省したり。

色々と凹んだり凹んだりしましたが、楽しい勉強会(カンファレンス?)でした。

今度から勉強会等の懇親会は、片隅で佇んでるだけでもいいから参加しよう。


to 未来の自分

2011年11月2日水曜日

コマンド3発で割と最近のvim環境が構築できるパッケージを作ってみた


社内でuniteを布教しようとするも、vimscriptはインストールが面倒くさいと、なかなか広まらないので、makeコマンドを打てば勝手に環境を構築してくれるパッケージを作りました。

https://github.com/kmnk/vimrc-builder

Shougoさん作の neobundle.vim を使わせて頂いて、もりもり僕が割と良く使う vim plugin をインストールして、とりあえず使えるようにします。


$ git clone git://github.com/kmnk/vimrc-builder.git
$ cd vimrc-builder
$ make

mapleader を Space にしていて、unite 関連のkeymapは基本的に Leader × 2 を始動にしているので、大体はスペース2連の後何がしかを打つと unite の何かが動くようにしています。


https://github.com/kmnk/vimrc-builder/blob/master/vim/profiles/unite.vim


これを基にして、社内環境に合わせてカスタマイズした物を社内リポジトリにアップしてみようかと目論んでいますが、使われるかなぁ。。


精神に余裕のあるときにデフォルトで入れているキーマップを書きます。

2011年8月7日日曜日

一日に30分節約できるかもしれない変態キーバインド(3/3)

IMEのON/OFF切り替えが人間には不可能な件


コーディングに関わらず、日本にいる限り日本語を入力することは避けられないことだと思われます。
しかし、この切り替えを行うためのトリガーとなっている半角/全角キーは人の手が届かない場所に配置されています。

日本で生きていくために、キーバインドでホームポジションに近づけます。

IMEのプロパティ、キー設定ツールで以下のように設定を行います。


これにより、IME ON/OFF 周りで以下のような操作が設定されます。
  • 文字入力状態外で無変換を押すと必ず IME が OFF になる
  • 文字入力状態外で変換を押すと必ず IME が ON になる
  • 文字入力中に無変換を押すと入力中の文字が半角になる(F8と同じ動作)
  • 文字入力中に変換を押すと入力中の文字が全角英数字になる(F9と同じ動作)
  • 文字入力中にひらがな/カタカナを押すと入力中の文字が全角カタカナになる(F7と同じ動作)


IMEのON/OFF以外に、日本語を入力する際に良く使うファンクションキーの動作を親指で自然に押すことのできるキーへ充てることで、人間の指でも無理なく日本語が打てるようになります。

よく使うキーが人外の域にいる件


日ごろコードを書く上で使うキーとして Enter や BackSpaceがあります。
また、自分はエディタとしてvimを使っているため、ショートカットのための Ctrl やノーマルモードへ戻るための Esc も非常に頻繁に使います。

これらのキーは、非常に良く使われるにもかかわらず、人の手では到達することができない、人外の域に生息しています。

キーバインドでホームポジションに近づけるしか生きる術はないでしょう。

以下を dot.nodoka に追記し、再読み込みを行います。

https://gist.github.com/1130249

これによって、以下のキーバインドが設定されます。
  • CapsLockキーを一度押すとEscが入力される
  • CapsLockキーを押しながら別のキー(例えばx)を入力すると、Ctrl + x が入力される
  • Ctrl + h(つまり、CapsLock + h)を入力すると、BackSpaceが入力される
  • セミコロンを入力すると、Enterキーが入力される
  • Ctrl + ; を入力すると、セミコロンが入力される


ここで、最も異質なのがセミコロンをEnterとしてしまうところですが、Enterキーというのはコーディングにおいて最もよく使うキーのひとつであることは自明なので、セミコロンを退避させてEnterキーに差し替えることはそれほど不自然なことではないでしょう。

一部の記号が人間に押されることを考慮していない件


コーディングにおいては、キャップ(^)やバックスラッシュ(\)等、一般の会話では用いられない記号を打ち込まなければならない場合が多々あります。
しかし、これらのキーはあまり用いられないためか、人間に押されることを考慮していない位置のキーに配置されています。

コーディングを続けるためにはキーバインドで我々だって人間なんだということを主張しなければなりません。

以下を dot.nodoka に追記して、再読み込みします。

https://gist.github.com/1130266

この設定によって、以下の記号を日ごろ打つ我々も人間なんだと主張することができます。
  • ^ (Ctrl + 無変換)
  • ~ (Shift + 無変換)
  • | (Shift + Space)
  • - (Ctrl + 変換)
  • _ (Shift + 変換)
  • = (Ctrl + ひらがな)
  • + (Shift + ひらがな)
  • \ (Ctrl + /)
  • ` (Ctrl + ‘)


Shift + Space はブラウジングなどで用いる可能性があるため、充てることができないかもしれません。適宜調整してください。

キーを拡張しても今までのキーを押してしまって慣れることができない


人に押すことのできないキーを押す技術を身に付けてしまったことで、本来の人間の姿を取り戻せなくなってしまった場合、どうにか矯正を行っていくしかありません。

以下のキーバインドを設定することで、人外の力を制限することができます。

https://gist.github.com/1130276

この制限は非常に強力なものであるため、よく考えて使う必要があります。
人外の力が弱まり必要がなくなったり、ストレスで寝込んでしまうなどの症状が現れたりした場合は、冒頭に # でコメントアウトしながら調整を行いましょう。

人間の手について考えながらキーを配置していたら自分のキーボードを触る人が居なくなった


キーバインドについて深く考察を進めていると、次第に自分のキーボードを触る人が減ってくる可能性があります。

キーの配置は人それぞれ最適なものが異なるため、自分に最適なものを突き詰めていくに従い、その他の人の最適なキー配置との距離が次第に広がっていくことは仕方がないことです。
しかし、ペアプログラミングや何かちょっとした操作を人に行ってもらうときなどに、自分以外の人が触ることのできないままでは、何かと不都合が発生します。
そのため、以下の一行を追加して人に使用してもらうときはあらゆるキーバインドを一度リセットする準備をしておきます。

key Pause = &LoadSetting("日本語 109 キーボード")


この設定により、Pauseキーを押すことで、それ以後、そのキーボードは元の「人間には扱いづらい一般的なキー配置」の姿に戻ります。
再度自分の作業に戻るときは、のどかの設定から再読み込みを行いましょう。

最後は自分で設定する


これはキーバインドに限ったことではないですが、設定はできる限り自分で一度書いてみるのが良いと思います。

自分で書くことで、「この配置はちょっと違和感があるが、変更するのが面倒」、「ここにこのキーを配置すればうまいこと行きそうだけど、設定方法が分からない」、「この文字を打ちたいのに何処に配置したか忘れてしまった」というようなことが少なくなってきます。


まとめ


以上、長々とキーボードの人間最適化について書きました。

まとめると、
  • キーボードはコーディングを行う人間に適した配置になっていない
  • 人間の手に適したキー配置を行うことで一日30分節約できる(かもしれない)
  • キーバインドソフトはのどか(or 窓使いの憂鬱関連)がお勧め
  • とりあえず以下を設定するとキー配列のKMNK最適化が行われる
  • キーバインドは一日してならず


という感じになった気がします。

紹介した以外にも自分最適化のために設定しているキーバインドはいくつかあるのですが、これは仕事環境や用いているエディタなどに依存してくるため、今回紹介はしませんでした。

自分の現行の設定はgitの構成を変更していなければおそらく以下から見られると思います。

https://github.com/kmnk/config/blob/master/dotfiles/dot.nodoka

何かおかしかったり、より良い設定などがあればお知らせいただけると非常にうれしいです。

また、こんなキー配列にしたらすごく捗るよ!とかも教えていただけると有り難いです。

ついこの前も、ずいぶん昔の記事なのですが、 http://pi200k.blog35.fc2.com/?no=70 のような配置を実践している方が居て、非常に夢がふくらみました。

Kinesisを買うことも一つの答えではあると思うのですが、どのマシンでもキーボードでも設定ファイルさえ読み込めば自己最適化されるというようなキー配置を色々と模索して、新たな配置を考えたら垂れ流していきたいと思います。