2008-03 - while ("im automaton");

Vim: 起動済みのVimプロセスを他所からインタラクティブに操作したい

2008-03-30T18:53:00 / vim / comment

最近は一度Vimを起動したらPCシャットダウンまで終了しないと言ってもいいくらいの使い方をしているのですが、稀にGNU screenの別のウィンドウから起動済みのVimのプロセスを操作したい場合があります。つまり、ウィンドウAとウィンドウBがあったとして、両方から同一のVimプロセスをインタラクティブに操作したいということです。

例えば、カレントディレクトリのファイルを開いて多少の編集をし、結果を起動済みのVimプロセスの適当なバッファにコピペするとします。GNU screenや端末エミュレータ自体の機能を用いてコピペすることは不可能ではないですが、'nowrap'や'number'の状態で正しくコピーすることはまず不可能ですし、コピーの種類(文字単位、行単位、矩形単位)の情報が落ちるので思ったようなペーストができませんし、何よりVimの完全なキーバインドが使えないので不便です。

Emacsにはemacsclientというものがあり、上記のようなことは不可能ではないようです。一方、Vimにも類似する機能(+clientserver)はあるのですが、あくまで起動済みのプロセスで指定されたファイルを開いたりスクリプトを実行したりできるだけで、インタラクティブに操作できる訳ではありません。また、*nixでは+clientserverにはX11が必須のため、coLinux使いの自分には余計にアレです。

GNU screenを上手く使えば不可能ではないような気がするのですけど、どうにかして実現できませんかね。

Mac OS向けのキーボードカスタマイズソフト

2008-03-30T13:15:00 / mac / comment

MacBookを注文したはいいのですが、Windowsでいう窓使いの憂鬱的なソフトがあるかどうか分からなかったので現在調査中です。以下、発見した順に適当なメモをば:

KeyRemap4MacBook: まだソースコードを見てないので詳しいことは分かりませんが、ドキュメントとスクリーンショットから察するに、キーの役割の置き換えはできるものの、それは事前に定義されているセットの中から選択する形で、それが繭使い的には合いません。まあその辺は既に誰かがどうにかしてそうな気もしますし、されてないなら自分でどうにかするかなぁ。
DoubleCommand: これもKeyRemap4MacBookと同じ形態なのでアウト。
Tesla: これは親指シフト使い用なので関係ない。

他にはあるのかなぁ。

しかしKeyRemap4MacBookやDoubleCommandのスクリーンショットを見て気になったのですが、Fnキーの置き換えができるようなのです。普通はソフトウェア側でどうこうできるキーではないと思うのですけど、MacBookのものはShift等のモディファイヤーと同じ扱いなのでしょうか。

それとMacBook到着後の使い方を考えてみたところ、HHKB接続時とそうでないときで設定を切り替えたいのですよね。設定を考えると以下の通り:

HHKB使用時: 右Shift ⇒ \ / | (Shiftとしても使えるようにしておく); 右Alt ⇒ IME on/off切り替え; CapsLock ⇒ 無効
MacBookのキーボード使用時: CapsLock ⇒ Ctrl; 左Option ⇔ 左Command; 右Option ⇔ 右Command; Delete ⇔ \ / |; 右Shift ⇒ \ / | (Shiftとしても使えるようにしておく)

これぐらいか。ただEsc周りの配列の違いはどうしたものか。アプリケーション単位での設定もできた方が良いけど、現時点で活用してるのはIrfanViewぐらいで、これはMacでは使えないので、なくてもどうにかなるかなぁ。

Twiter @vmwarefusionに吹いた

2008-03-30T09:46:00 / twitter, mac / comment

@kana1: Q. VMWare Fusion vs. Parallels Desktop -- which is the best one?
@vmwarefusion: @kana1 We have an opinion...but might be biased! They're both free to try. VMware Fusion has a 30 day free trial. Bet you like it more ; )

Mac関係の情報収集中、Windowsとの併用を考えるとVMWare FusionとParallels Desktopという2つの選択肢があり、どちらが良いんだろうと思ってTwitterでぼやいていたのですが、予想外の方向からのreplyがあって吹きました。

Twitterは個人以外にも法人やbotのアカウントも色々と存在します。中には無差別にfollowしつつ延々と偏ったメッセージを垂れ流すspamなアカウントも存在しますが、そういうものは分かり易いので即blockしています。そういう意味では@vmwarefusionも広告用なのでアレなのですけど、なんというか、timelineから漂う人力感が微笑ましいので、許す。but might be biasedと正直なところもポイント。

しかし実際のところはどうなんでしょうね。Wikipediaでの両ソフトの比較記事を見るに、パフォーマンスならVMWare Fusionに、Macとの統合性ならParallels Desktopに軍配が上がるようですが、具体的にどういうことなのかは実際に試してみないとなんとも言えません。両ソフトはApple Storeで販売されているものの、Apple社ウェブサイトの各種紹介記事ではParallels Desktopの名前しか出てこないところからは、統合具合は良い感じなのかなぁ、とは思いますけど。

律速ねんどろいど(FinePix A900購入編)

2008-03-29T18:33:00 / diary, photo / comment

えろげのタイムセール狙いで寄ったPCショップの店頭でFinePix A900が相場より安め(のはず)の13000円弱で売り出されていました。「電源が単3電池」「外部記録メディアにSDカードが使える」「近距離の撮影がそれなりにできる」「スローシンクロが使える」という条件を満たしていましたし、さらに値段が手頃だったので、つい、買ってしまいました。デジタルカメラについては全くもって素人なので、これが良い買い物だったかどうかは分かりませんけど、その辺りは使っていくうちに学んでいけばいいかと思っています。

取り敢えず適当にねんどろいどの長門有希を撮ってみましたけど、やはり携帯電話のカメラとは画質が全然違いますね。はっきりくっきり。しかし、これだけ画質が良いならちゃんと撮影できるよう勉強しないといけない気分になってきました。それと構図や小物との絡ませ方も今後の課題。

画質と言えばFlickrのFree Acountの制限が気になってきました。アップロードした画像が3488*2616でも閲覧できるサイズは1024*768までですし、毎月のアップロード上限100MBも個々のファイルサイズが大きいのですぐに超過しそうですし。今までは小ぶりのサイズの画像しかアップロードしていなかったので制限事項は全然気にならなかったのですけどね。今ならちょうどドル安ですし、新規Pro Account取得でMOO MiniCards 10枚無料とのことなので、アップグレードするのもいいかも知れません。思えばMOOは前々から試してみたいとは思っていましたけど、高画質の画像が撮れなかったので諦めていたんですよね。わー、どうしましょう。この散財スパイラル。

散財といえば、最近発表されたねんどろいどの新作がパステルいんくで吹きました。全く持って興味はなかったのですが、紹介ページ右上のなんともやるせない表情に心が揺らぎそうです。破壊力、高いです。助けてください。

MacBook、注文

2008-03-28T22:55:00 / diary, prog, mac / comment

「MacBookが何故か唐突に欲しくなってきた」とぼやいてから約18時間。列挙していた問題点は大体解決できそうなことが判明したので、注文してしまいました。久々の大きい買い物なので色々と震えています。ぶるぶる。

注文内容は一番安いモデル+HDD 250GB+US配列キーボード+DVIアダプターで、税抜131375円。AppleCareはデフォルトの保証期間1年以内なら何時購入しても問題ないので一先ず保留することにしました。

ついでなのでMac+iPodの同時購入でのキャッシュバックキャンペーンを利用してiPod nanoも注文しました。この手のガジェットには全く興味がなかったのですが、実質無料で手に入れられるので、ポチっと。

注文する際に知ったのですが、オンラインのApple StoreではiPodへのレーザー刻印の無料サービスがあるとのことなので、まあどうせならと、刻印を入れてもらうことにしました。刻印可能領域は2行分だったので、取り敢えず1行目を「while ("im automaton");」、2行目をURIとしたところ、日本語のメッセージが長すぎるか、「"~*<>\」等のご利用いただけない記号や文字が含まれていますとのことで。ちくしょうだれがこんなことを。仕方がないので別のものに変えましたけど、何故「"」が不可なんでしょうね。

さて、今から到着までどきどきしっぱなしです。どうしましょうどうしましょう。

MacBookが何故か唐突に欲しくなってきた

2008-03-27T15:12:00 / diary, prog / comment

いい加減、自宅で使用中のデスクトップPCの性能に限界を感じ始めてきたので、新しいマシンを買おうかなと思っているのですが、Twitter界隈(どこだ)でのMacBookの盛り上がり具合を見て何となくAppleのウェブサイトを眺めていたら、MacBookが物凄い勢いで欲しくなってきました。

購入に際しては色々と選択肢があるのですが、まず最初の選択肢は「デスクトップPCとノートPCのどちらにするか」です。今の自宅の環境では新たにデスクトップPCを買っても置く場所がなく、また夏場は暑く冬場は寒い自室の環境を考慮するとポータブルなノートPCの方が色々と便利だと思います。性能面を考えるとノートPCの方は多少の難があるのでしょうけど、今時のノートPCなら現在使用中のマシンより遥かに高性能なので、そこは大して気にならないはずです(書いてて少し悲しくなってきた)。という訳でノートPCにしようと思っています。

次の選択肢は「どのOSにするか」です。今まではWindowsを使っていたのですが、最近だと世間はVista一色です。しかしVistaは窓使いの憂鬱的にかなりの難がありますし、XPもいずれサポートが終わることを考えると、他の環境に触れてみるいい機会かも知れません。振り返ってみればゲーム以外の点でWindowsにこだわる理由はありませんし、ゲームがしたければ今のマシンを使うか、VMWareでも使えばいいのです。いっそWindowsという選択肢をばっさり切り落としてしまえば残りはMac系か、OS無搭載モデルに適当なdistroを入れるということになります(OS搭載済みだとその価格分だけ損)。思えばMacは全然使ったことがないので、じゃあMacにしてみようかということになります。

新しいマシンはいつか買おうとは思っていたのですが、学割の存在に加えMac+iPodの同時購入でのキャッシュバックキャンペーンがあることに(不幸にも)気付いてしまったので、これを機に買ってしまおうかと悩んでいます。

ただ問題は、現行の環境からちゃんと移行できるかどうかです。思いついた範囲での問題点は次の通り:

各種アプリケーションは移植されてるか? 代替となるものはあるのか?: AVG (アンチウィルス); ZoneAlarm (ファイヤーウォール); PuTTY; Opera; Exact Audio Copy; foobar2000 (特に.(tta+cue).mkaの再生); IrfanView; JTrim; bluewind; 窓使いの憂鬱; 他は端末内で動くものばかりで、そういうものは移植されてるだろうから除外。
NTFSでフォーマットされたディスクドライブはMacから読み書きできるか?: バックアップと音楽データとゲーム置き場の外付けHDDがNTFSなので、読み書きできないと悲しいことになります。

上記の問題を全て解決できるのであれば躊躇する理由はなくなるのですけどね。後で調べる予定。

残りの問題は、MacBook、MacBook Air、MacBook Proのどれを選ぶかです。用途は現在使用中のデスクトップPCの代替で、頻繁に持ち運びするということはありません。MacBook Airはサブマシンという位置付けなら良いのでしょうけど、メインで使うには心許ないので除外します。

となると残りはMacBookかMacBook Pro。両者のスペックを比較してみて思った点は以下の通り:

CPUは体感できるほどの差はないだろうからどれでもいい。
メモリは自分で4GBまで積むのでどれでもいい(むしろデフォルトで積まれている分が多いと損)。
光学ドライブはDVDを焼くことがないのでどれでもいい。
ビデオカードはゲームや巨大モニターを使うのでもなければどうでもいい。外部モニターで利用できる解像度については、MacBookは1920x1200まで、MacBook Proは2560x1600までサポートされているけれど、どちらにせよそんなモニターは身近にないし、仮に買うにしてもMacBookもう1台余裕で買えてしまう値段である。
拡張性はノートにそれを期待してないし、ハードに疎い自分にはある意味どうでもいい。強いて言えばUSBポートはHHKB用、外付けHDD用、予備の3つが欲しいかなぁ。
モニターは大きい方が良いのでMacBook Proに軍配が上がる。でも自宅で使うならば外部モニターを使えばいいことだし、本体モニター+外部モニターのデュアルモニターで使うことも可能なので、本体モニターが小さくても問題ないのではないか。強いて言えばMacBookはモニターのパネルがグレア加工のものしか選べない点が問題(ただこれは適当なフィルターを付ければいいと思うので別にいいかなぁ)。

むぅ。考えれば考えるほどMacBookの一番安いモデルで十分な気がしてきました。オプションとしてHDD増量+US配列キーボード+外部モニター用アダプタ+AppleCareも付けると学割価格166294円。よーし、ついでにデジカメとHHKB Pro2も買って20万ぐらいぱーっと使っチャオっかな! 貯金大崩壊ですけど。

このサイトにコメントを付けられるシステムを書こうかしら

2008-03-27T15:06:00 / prog, site / comment

このサイトの内容はほぼ全て静的に生成されているのですが、これだとコメントを付けられるようなシステムを導入し難いです。しかし最近になってはてなスターのような形態であれば不可能ではない気付いたので、気が向いたらjsの勉強がてらに書いてみようかと思ったり思わなかったり。

律速ねんどろいど

2008-03-25T20:08:00 / diary, figure / comment

日夜某所のねんどろいどスレを眺めていたら、いまいち好みでなかったらきすたも許せそうになってきました。主にこなたの「＞∀＜」顔が。デジカメも手を出しそうで困ってます。これで小物を揃え始めたら色々とアレ。

しかし冷静に考えてみると、現時点でナオ2000円+長門有希3000円+長門有希(5月再販分)2600円+メリッサ・セラフィ(6月発売予定分)3000円の計10600円を消費しており、さらに前述のねんどろいどスレで「ナオ頭部+アル・アジフ胴体」の絶妙なコンボの写真を見せられたがためにアル・アジフも購入予定なので約13600円を消費済みです。

さらに言えば涼宮ハルヒは「ぐぬぬ」顔が可愛いし、朝比奈みくるは胴体が色々と使えそうだし、涼宮ハルヒの憂鬱バニーガールセットは各パーツが色々と使えそうだけど限定品だから今更入手しようにも価格的な意味でアレだからなぁ、って、おちつけ。さすがにそこまで使うなら先に新しいPCを買うよ!

家電量販店で適当にデジカメを眺めてみた

2008-03-23T19:57:00 / diary / comment

家電量販店で適当にデジカメを眺めてみました。カタログだけじゃ分からない部分もあるので展示されてるサンプルを手に取ったり取らなかったり。

しかし何を基準に選んだらいいんでしょうね? 自分で考えてみた範囲では以下の通り:

電源: 乾電池かなぁ。専用バッテリーは今一良いイメージがない。予備を用意しにくいとか。
記録媒体: SDカードがいい。色々と使い回しが利くので。
被写体: ねんどろいど。だから近距離のものをちゃんと撮れればいい。
出力: PCモニターのみ。印刷は考えていないし、プリンターもない。
予算: ない。

店頭で見た範囲では、電源と記録媒体の指定があるなら結構候補が絞られそうでした。まあ疎いし今すぐ要る訳でもないのでまた暇になったときに考えてみます。

USBポートが足りないので適当なPCIカードを買った

2008-03-23T19:27:00 / diary, pc / comment

今のPCのUSBポートが2個しかなく、キーボードと外付けHDDで埋まってるので空きが0とそれなりに不便なので、というかそもそもUSB 1.xのため外付けHDDにはキツいので、適当なPCIカードを買いました。いやー、USB 2.0ははやいですねー。だって外付けHDDにあるムービーが普通に再生できるんですよー。ビットレート高くなってもブツブツ途切れないんですよー。すごい、ねー。ちくしょう書いてて虚しくなってきた。

先日、typesterさんから「いまどきパケホーダイじゃないのかよ」的なDISを受けましたが、ハードウェア的な意味ならいくらでもDISられる自信がありますよ。搭載メモリ768MBとか。

今年最大のドジ: 「ねんどろいど長門有希」×2

2008-03-22T20:17:00 / diary, figure / comment

5月に再販されるねんどろいど長門有希をsoftmap.comで予約。
翌日、Amazon.co.jpで同製品の在庫の販売が行われているとの情報を得る。残り数個。思わず注文。
重複はアレなのでsofmap.comでの予約分をキャンセルしようとしたが、既にできない状態になっていた。
仕方がないのでAmazon.co.jpでの注文分をキャンセルしようとしたが、既にできない状態になっていた。

さあ笑え! 色々と!

もう何かどうでもよくなってきたので勢いに乗ってねんどろいどメリッサ・セラフィも予約するよ! 1/8メリッサ・セラフィも(主にかぼちゃ部分が)欲しいけど踏み止まる! ああ、でも色々な写真を見ていたら両方欲しい。

「ねんどろいどナオ」購入

2008-03-21T23:50:00 / diary, figure / comment

今までフィギュアの類は全然興味がなかったのですが、近頃発見したねんどろいど関連のスレッドを眺めていたら楽しそうなので、つい、ねんどろいどのナオを購入してしまいました。ふらりと立ち寄った店で2000円のものを見つけてしまったのが運の尽きです(安くても2500円のものしか見たことがなかった)。

実物を触っていて思ったのですが、これはこれでなかなか面白く、小物等を色々と揃えて遊びたくなる気持ちは分からないでもないです。ただ、撮ろうにも携帯電話のカメラでは今一なのでちゃんとしたカメラを買いたい気分にもなってきました。折りしも先日の影響でカメラにも多少は興味が湧いてきましたし。

ああ、どうしましょう、この出費スパイラル。

KAYAC会社説明会に行ってきた

2008-03-21T21:21:00 / off, diary / comment

2008-03-18

20:00ぐらい: 夜行バスに乗って出発。乗り物に強くないのに酔い止めを忘れて序盤戦からかなり劣勢を強いられる。
21:00: 本を読もうにも酔うから読めないので悶々とする。
22:00: 開き直って寝ようにもガコンガコン揺れるのでなかなか寝付けない。

2008-03-19

08:00ぐらい: 東京駅に到着。ちょっと眠い。
08:05ぐらい: 鎌倉駅までの路線を確認して、乗り場まで行こうとするが、広くて入り組んでて人が多くて迷い死にそうになる。
08:10ぐらい: ようやく目的のホームに辿り着くが、電車の窓から覗く圧縮状態に気圧されて1台スルーした。
08:20ぐらい: しかたがないので満員電車でも乗り込んでみた。嫌になった。
09:20ぐらい: 鎌倉駅に到着。マクドナルドで朝食。
09:50ぐらい: KAYAC本社に向けて出発。左手に真っ赤な鳥居の脇を進みというフレーズを頼りにマクドナルドのすぐ隣の鳥居に向かって直進するが、正しくはもう一つ東側の道だった。教会らしきものが見当たらないことに気付いて進路修正。
10:10ぐらい: 受付開始まで時間があるので八幡宮を眺める。
10:40ぐらい: 会場に到着。三番目くらいだった。空いていたので前方中央に座る。
10:55ぐらい: 10人少々の人が集まる。ただ参加者の面々に微妙な違和感を感じる。
11:00-12:10ぐらい: ふつうの説明会。ただし大塚さんの顔だけBM11メンバー紹介での濃いアイコンに変換されて見えてしまって困った。
12:15ぐらい: グループ面接までの微妙な待ち時間の間、体をほぐそうと足を伸ばしたら左足のふくらはぎ辺りを攣った。半泣き。その後、立ち上がろうとして天井に頭をぶつける。なんというドジ。もう面接とかどうでもよくなってくる。
12:20ぐらい: グループ面接開始。質問に答えつつも、説明会開始前での違和感は技術部志望の人がほとんどいないことだと思い始める。
12:50ぐらい: アンケート用紙に回答。その後、オフィスを一通り案内される。途中、案内役の方から「今日は技術部志望の人って君だけですよー」と言われて吹いた。少ないどころの話ではなかった。; 案内役の方が通りがかった場所にいる社員の方の紹介をしたりしなかったり。; トラックボールが4個くらい転がっており、うち2個はKensington Expert Mouseだった。欲しい。; エディタはEmacs派が多いように見えた。xyzzy派も存在。むぅ。; cho45さんが何故かKAYACに居て吹いた。呼ばれ方も「チョヨンゴー」と謎の国籍風味でさらに吹いた。
13:10ぐらい: 生のtypesterさんと対面。何を喋っていいか判断に困って固まっていたらyokoさんがやってきてさらに困る。そうこうしているうちにbowlsで一緒に昼食の流れに。
13:30ぐらい: bowlsで昼食。会社説明会にて社長から「今日は説明会参加者の皆さんに特別メニューとしてカツ丼を用意してます」という発言があったのですが、ガセでした。ミソカツ丼はありましたけど。; githubだとかデジカメだとかその他色々な雑談。デジカメには全然興味なかったのですが、yokoさんが当日持っていたカメラについて調べてみたところ、かなりの値段で吹いた。
中略
21:00ぐらい: typesterさん、yokoさん、他KAYAC社員の方の数名と呑む。酔いが回ってきたtypesterさんからためになるお話が色々と。どこまで書いていいか微妙なところなので詳細は割愛。

疲れてるので今日はこの辺で中断。

Vim: 'filetype'は複数のもの混合できる

2008-03-15T23:36:00 / vim / comment

Vimの'filetype' (と'syntax')は複数の値を混合することができます(例: :setfiletype c.doxygen)。

ふと思ったのですが、これをちょっと工夫すればEmacsでいうminor modesもどきを実現できないでしょうか?

Vim: Emacsのmajor modesやminor modesに等価なもの

2008-03-15T23:12:00 / vim / comment

Vimにおいて、Emacsのmajor modesやminor modesに等価なものというのは、多分、次の通り:

Major modes	filetype plugins
Minor modes	一部の(global) plugins、あるいはオプションやkey mappingsの色々な設定の集合

ただ、global pluginsはon/offを簡単に切り替えられるわけではないので、微妙なところ。

zshに移行中

2008-03-15T22:29:00 / zsh / comment

ようやく気が向いてきたのでzshへの移行を始めました(元はbash使い)。手持ちのスクリプトの幾つかのポートと、細かい設定の調整を除けば大体の作業は終わりました。bash++的な使い方であれば何とかなるだろうと思いchshも済ませたのですが、まだ何となく怖い部分もあるので、zsh使用中であることを明示するためにプロンプトを$からYUKI.N>に変えてみました。

結果: たまにシェルに戻ったときに吹く。でも多少の和み成分があるので、もう少しこのままにしてみます。

KAYAC会社説明会に行きます

2008-03-15T21:41:00 / off, diary / comment

3月19日に開催されるKAYACの会社説明会に行きます。ついでにbowlsでBUDDHA丼あたりをニヤニヤしながら食べる予定です。無駄にルービックキューブを回してる人がいたら恐らく私なので気軽に声をかけてください。無理か。

その会社説明会なのですが、気になることが一つあります。一昨日になって持参物に関する変更のお知らせがあったのですが、技術部希望の参加者に指定されていた持参物のうち、Webの作品があればご持参くださいという項目が削除されました。なぜ削除されたのか色々と想像の余地はあるのですが、個人的にはグループ面談でコード面接が行われることを期待しています。無理か。

余談: 交通手段としては夜行バスを使う予定なのですが、予約が遅れたために復路の便が希望通りに行かず、1日余分に足止めを食らうことになってしまいました。という訳で、19日16:00くらいから20日18:00くらいまで暇なので、誰か一緒に飲んだり食べたり話したりIIDXしたりDDRしたりしませんか? 無理か。

Vim: 'langmap'を使えばQWERTY以外のキーボード配列への移行が簡単にできそう

2008-03-12T06:02:00 / vim / comment

Vim、というかviのキーバインドはQWERTYに凄まじく依存しているため、DvorakだのColemakだのの他のキーボード配列に移行することは果てしなく困難です。

解決方法はNormal/Visual/Operator-pending modeにおける各キーをYour-Favorite-LayoutからQWERTYに変換することで、その実現方法として真っ先に思いつくのはkey mappingsなのですが、これは事実上使用不可能です。何故なら他のkey mappingsと思いっ切り競合するからです。

どうしたものかと思っていたのですが、'langmap'を使えば簡単に実現できそうなことに気付きました。'langmap'の本来の用途とは微妙に違うと思うのですが、性質的には上記の問題を解決するには必要十分です。

'langmap'の効果は、例えば:set langmap=feと設定した場合、Normal/Visual/Operator-pending modeで入力したfは全てeに変換されます。その後にkey mappingsの変換が行われるため、既存のkey mappingsとも共存できます。

これならVim使いのキーボード配列移行の敷居はかなり下がったような、そうでもないような。

Vim Hack: 個々のhackの差分を抽出しやすいようgitリポジトリの内容を修正するときの手順

2008-03-11T19:58:00 / vim, hack, git / comment

私家版Vimリポジトリでのブランチの作り方を間違えていたので、その修正方法の話。gitにはブランチの状態を任意の時点に戻すgit-resetというコマンドと、任意のcommit objectの変更内容を適用するgit-cherry-pickというコマンドがあるので、これを利用すれば割と簡単にリポジトリの内容を修正できる。以下、その手順:

ブランチmasterの変更履歴、特にcommit objectのIDをメモしておく(今回は修正すべき変更が全てmasterに対して線形に並んでいたので割と抽出し易かった)。
```
$ git-log master >log
```
機能追加作業のベースとなる状態を表すブランチhack/baseを作成する。ここではオリジナルのソースコードの最新版(sf/trunk)をベースにした(実際にはhack/baseに対して多少の変更が加わっているが、ここで述べる内容とは関係ないので省略する)。
```
$ git-branch hack/base sf/trunk
```
既存の機能追加用のブランチhack/fooを削除し、hack/baseをベースにして作成しなおす(git-resetで十分かも知れないけど、念のため)。
```
$ git-branch -D hack/foo
$ git-branch hack/foo hack/base
```
hack/fooに対して以前のコミットの内容を適用する。各コミットのIDは最初の手順でメモしておいたlogから適当に判断すること。
```
$ git-checkout hack/foo
$ git-cherry-pick commit-object-id-1
  ...
$ git-cherry-pick commit-object-id-N
```
hack/foo以外の機能追加用ブランチについても上記と同様の作業を行う。
masterの内容をhack/baseと同じ状態に戻す。
```
$ git-checkout master
$ git-reset --hard hack/base
```
機能追加用ブランチの変更内容をmasterへマージする。コンフリクトが発生した場合は適宜対処する。
```
$ git-merge hack/foo
  ...
$ git-merge hack/bar
```

以上の方法でリポジトリの内容を修正できた(参考: 現在の私家版Vimリポジトリの状態)。

ああ、でもこれ、sf/trunkが更新された場合はどう対処しよう。sf/trunkからhack/base、hack/baseからmasterへと変更を伝播させればいいのだろうけど、rebaseを使うべきなのかmergeを使うべきなのか。hack/baseに対してはrebaseにした方が良いだろうけど、masterは変更履歴の長さを考えるとrebaseには時間がかかりそうで嫌だな。

Vim Hack: ブランチの作り方を間違えてたかも

2008-03-11T18:48:00 / vim, hack, git / comment

私家版Vimのリポジトリの話。何か機能を追加するときはブランチmasterの最新版をベースにブランチhack/fooを作成し、完成したらmasterにマージする形を取っていたが、これではオリジナルのソースコードから個々の機能追加を行うためのパッチを抽出し辛いことに気付いた。masterの最新版は他の変更が混ざっているので、それをベースにしては不味い。

どちらかというと、オリジナルのソースコードのある時点をベースにしてブランチを作成した方が良かったのだろう。

でも、今の段階からどうやって修正しよう? 幸い、gitにはgit-resetという素晴らしいコマンドがあるので、ブランチの変更履歴を任意の時点に戻すことは簡単にできる。それに、masterへの変更履歴はまだ線形なので、差分の抽出はまだ楽にできそうではある。

ちなみにgit-resetはかなり熱いコマンドなのでマニュアルに目を通しておいて損はない。

repo.or.czに私家版Vimを登録してみた

2008-03-11T04:55:00 / vim, hack / comment

repo.or.czというgitリポジトリのホスティングを行っているサイトがあったので、私家版Vimのリポジトリを登録してみました。ソースコードを直接変更しないと実現できない機能は色々とあるので、適当に弄ったりする予定です。

Vim Hack: Normal modeでマルチバイト文字を入力した際に自動的にInsert modeに移行する

2008-03-11T04:32:00 / vim, hack / comment

Vim使用時、Normal modeのままでそれなりの長さの日本語を入力してしまって悲しいことになる場合があるので、Normal modeでマルチバイト文字を入力した際に自動的にInsert modeに移行するよう変更してみました。

これはさすがにVim script側では対処の使用がないので、ソースコードを直接変更せざるを得ませんでした。方針としては、Normal modeでのコマンドを割り当てられていないキーが入力された場合にNCmdUndefinedというイベントを発行するようにソースコードを変更し、残りの処理はVim script側で対処することにしました。

Vim script側での設定は次の通り:

silent! autocmd MyAutoCmd NCmdUndefined *
  \ call <SID>ShiftToInsertMode(expand('<amatch>'))
function! s:ShiftToInsertMode(not_a_command_character)
  if char2nr(a:not_a_command_character) <= 0xFF  " not a multibyte character?
    return  " should beep as same as the default behavior, but how?
  endif

  " Take all keys in the typeahead buffer.
  let keys = a:not_a_command_character
  while !0
    let c = getchar(0)
    if c == 0
      break
    endif
    let keys .= nr2char(c)
  endwhile

  " Shfit to Insert mode, then emulate typing the keys.
  " Note: If :startinsert is used to shifting to Insert mode,
  "       instead of keys[0], unexpected string '<t_<fd>_>' will be inserted.
  call feedkeys('i', 'n')
  call feedkeys(keys, 't')
endfunction

実装でのポイントは次の通り:

Normal modeでのキー処理ルーチンnormal_cmd()はかなり長く、その中で直接イベントを発行(= :doautocmd相当のことを)しても安全かどうかは不明瞭。
Vim内部でのみ有効な特殊キーK_NCMDUNDEFINEDを定義し、それに対応する動作としてNCmdUndefinedの発行を割り当てた。
normal_cmd()からはK_NCMDUNDEFINEDをキー入力バッファの先頭に挿入することにし、それによって間接的にイベントの発行を行うようにした。

gitリポジトリの内容をSubversionリポジトリに移すときの手順

2008-03-09T01:48:00 / git, svn / comment

ローカルにある独立したgitリポジトリ(git-cerejaと呼ぶことにする)の内容を、リモートのSubversionリポジトリ(svn-crと呼ぶことにする)に移すときの手順は次の通り:

(必要であれば) svn-crにgit-cerejaの内容を置くためのディレクトリを作成する。git-svnではSubversionリポジトリ内の既存のディレクトリしか操作できないため(git-svn clone --trunk foo/bar ...と存在しないディレクトリを指定するとエラーになる)。
```
$ svn mkdir -m '...' $SVN_CR_URL/platform/windows
$ svn mkdir -m '...' $SVN_CR_URL/platform/windows/cereja
$ svn mkdir -m '...' $SVN_CR_URL/platform/windows/cereja/{trunk,branches,tags}
```
git-cerejaにsvn-cr内の置き場所に対応するブランチcr-trunkを作成する。なお、git-cerejaには既に他のSubversionリポジトリが関連付けられている場合があるので、区別のために-Rと--prefixを指定している。
```
$ git-svn init -R cr --prefix cr/ -s $SVN_CR_URL/platform/windows/cereja .
$ git-svn fetch cr
$ git branch cr-trunk cr/trunk
```
cr-trunkにgit-cerejaの内容をコピーする。ここではcr-trunkにmasterの内容をマージし、またマージされる内容の変更履歴は省略することにした。
```
$ git merge --squash master
$ git commit -m '...'
```
cr-trunkにコピーされた内容をオリジナルのSubversionリポジトリにコミットする。
```
$ git-svn dcommit
```

以後、git-cerejaに加えられた新たな変更をsvn-crに移す場合、最後の2つの手順を行えばよい。

しかし、面倒な点がいくつかある:

最初の手順に書いたgit-svnの制限のために、svnを使わなければならない場合がある。
gitリポジトリ内のブランチを一括してSubversionリポジトリにコピーするのが面倒。
gitリポジトリ内のタグのコピーに関しても同様。特にSubversionリポジトリのタグはgitリポジトリ側からは一種のブランチという扱いになるだろうし。

Opera: 「'」に「Enter access key mode」を割り当てるとVimっぽくて便利

2008-03-08T23:24:00 / opera, vim / comment

Operaのショートカットキーの設定で、グループApplicationのところで'をEnter access key mode | Leave access key modeに割り当てると、Vimのジャンプっぽく'xの2ストロークで移動できるので便利ですよ。

Screenshot: Opera's Access Key Mode on Wikipedia

でもまあ、どマイナーかなぁ、この設定。

git: pull/pushはブランチ単位だからSVKのような任意のディレクトリ間のマージはできない

2008-03-07T19:03:00 / git, svn, svk / comment

前提条件

ローカルにある各種設定ファイルのリポジトリ: local-config; この中のサブディレクトリvim下にVimの設定ファイルがある。
CodeReposにあるVimの設定ファイルのリポジトリ: cr-dotfiles-vim-kana; CodeReposリポジトリ全体のうち/dotfiles/vim/kanaに対応する。

やりたいこと

local-configのサブディレクトリvimの内容をcr-dotfiles-vim-kanaへpushする。

だがしかし

軽く調べてみたのだけれど、gitのpull/pushはブランチ単位で行われるので、SVKのように任意のディレクトリ間でマージはできないようだ。

SVK/Subversionならできるのだが、これはブランチもタグも一種のディレクトリとして扱うというSubversionの内部構造に起因する。個人的にはこの設計は微妙だと思っていたのだけど、一応、こういうことができるというメリットはあるのか。

解決方法

分からない。pull/pushでの対象はrefspecで指定するが、これを構成する各refは「A 40-byte hex representation of a SHA1 or a name that denotes a particular object.」なので、もしかしたらrefspecにサブディレクトリに該当するtree objectを指定することでpull/push可能なのかも知れない。

試しにサブディレクトリvimのIDをrefspecに使ってみたが、pushもpullもエラーになってできなかった。ということはrefspecに使えるobjectはcommit objectかtag objectに限定されるのだろう。つまり、解決不能ということか。

$ cd ~/working/config


$ git push ~/working/coderepos/dotfiles-vim-kana $(git-ls-tree master vim | awk '{print $3}'):master
Pushing to /home/kana/working/coderepos/dotfiles-vim-kana
To /home/kana/working/coderepos/dotfiles-vim-kana
 ! [rejected]        5b5d3dacf256a47c992e0bea9439241561aaa3e0 -> master (non-fast forward)
error: failed to push to '/home/kana/working/coderepos/dotfiles-vim-kana'

$ ~/working/coderepos/dotfiles-vim-kana

$ git pull --no-commit ~/working/config $(cd ~/working/config; git ls-tree master vim | awk '{print $3}'):master
fatal: Couldn't find remote ref 5b5d3dacf256a47c992e0bea9439241561aaa3e0

少々手間はかかるが、取り敢えず次の準備を行えばgitでも任意のディレクトリ間のマージは可能であるようだ:

configの内容をdotfiles-vim-kanaのブランチtmpにコピーする。
```
$ git fetch ~/working/config master:tmp
```

tmpの内容をmasterと同一のディレクトリ構成になるよう修正する。

$ git checkout tmp
$ git rm $(echo * | grep -v vim)
$ git mv vim/* .
$ git commit -m 'Adjust the directory structure for further merging.' -a

masterにtmpの内容をマージする。これでconfigの内容がdotfiles-vim-kanaへマージされたことになる。この作業が終わったらtmpは削除して構わない(多分)。
```
$ git checkout master
$ git merge tmp
```

一度この作業を行った後はdotfiles-vim-kanaのmasterブランチからconfigの内容を直接pullできる(例: git checkout master && git pull ~/working/config)。SVKと違い、先程の作業でのディレクトリ構成の変更を考慮して適宜マージしてくれる。

git-svn: Subversionリポジトリの一部を履歴を端折ってcloneする際の注意点

2008-03-07T01:03:00 / git, svn / comment

CodeReposへのやりとりにgitを使おうと思い、手早くリポジトリをセットアップするため、対象をオリジナルのリポジトリの一部に限定かつ変更履歴を省略するため以下のようにしたところ、何もfetchされなくて困りました。

$ git-svn clone -r HEAD http://svn.coderepos.org/share/dotfiles/vim dotfiles-vim
Initialized empty Git repository in .git/

$

何が理由か色々と試してみたのですが、どうやら上記のようにリポジトリの一部/dotfiles/vimに限定してgit-svn cloneをする場合、-rで指定したリビジョンの範囲の変更に/dotfiles/vim下のファイルやディレクトリが含まれていなければならないようです(git-svn clone = git-svn init + git-svn fetchなのでfetchでも同じことが起こる)。

試した時点での/dotfiles/vimを含む最新のリビジョンは7491だったのですが、-r 7491:HEADでは最新の内容がfetchされるものの、-r 7492:HEADでは何もfetchされませんでした。

今までリポジトリ全体に対するgit-svn cloneしか行ったことがなかったので気付きませんでした。むぅ。

gitのデザインにセンスを感じてきた

2008-03-06T02:29:00 / git, prog / comment

gitを使い始めて2週間弱。徐々にgitのデザインにセンスを感じてきました。

他のバージョン管理システムと比べて明らかに多いコマンド群についてですが、これは単にUnix philosophyに従っているだけのことです。実際、高レベルなコマンドは低レベルなコマンドを組み合わせたシェルスクリプトやPerlスクリプトです。そして各コマンドの分類や粒度がすっきりしています。

また、他のシステムと比べて内部のデータが透明な点も挙げられます。各種設定項目は人間に可読な形で保存されていますし、データベースの構造もかなり分かり易いものです。そのため、各コマンドがどういう処理をしているのか想像がつき易いです。

低レベルのコマンドの概要については「A git core tutorial for developers」が、データベースについては「Git User's Manualの7. Git concepts - The Object Database」を読むといいです。普通に使う分にはあまり関係ない事柄なのですけど、知っておいて損はありません。

Vim scriptを書くときのtips

2008-03-03T23:53:00 / vim / comment

コードを書くスタイルは十人十色でしょうけれど、このくらいは気に掛けておいても損はないだろう的なVim scriptを書くときのtips:

コマンド名やオプション名の省略形を使わない: スクリプトを書くのは一度だけですが、後から何度も読みます。読み難い省略形を用いる必要性はありません。タイプが面倒ならば<C-x><C-v>を活用しましょう。; (これは私の推測ですが)省略形はインタラクティブに入力する際の利便性のために用意されているものです。それ以外の場面で積極的に使う必要性はありません(省略形で入力して後から補完で展開するのはアリでしょうけれど)。
Key mappingsの定義に:map系をできるだけ使わない: :map等で定義したkey mappingsは再展開されます。設定を何度も更新していった結果、思わぬところで再展開による副作用を被る可能性があります。再展開が必要なケースでなければ、再展開を行わない:noremap等を使うべきです。; 自分の経験上、key mappingsの再展開が必要なケースはほとんどありません。再展開が必要なケースというのは、<Plug>で始まるkey mappingsへ割り当てるときか、あるキーを他のキーと全く同じ意味にしたいときぐらいです。; ちなみに、自分の設定だと220個以上のkey mappingsの定義があるのですが、再展開が必要なものは30弱で、そのほとんどが他のkey mappingsのエイリアスを定義するためのものでした。
コマンドに:を前置しない: これは単に無視されます。無駄な記号を書く必要性はありません。
スクリプトローカルな関数の定義・呼び出し時に<SID>を使わない: <SID>を使わざるを得ない場合はユーザー定義のコマンド、key mappings、autocommandsの定義時か、一部オプションの値の設定時だけです。それ以外の箇所では使う必要性はありません。

TODO: 他、何か思い出したら追記すること。

gitでsvn exportと同等のことをする方法

2008-03-01T03:50:00 / git, tips / comment

git archive --prefix=dir/ id | tar xf -

idにはブランチ/タグの名前またはコミット/ツリー/タグのID (= SHA-1 hash)が使える。
dirは展開結果を特定ディレクトリにまとめるために必要。この場合、末尾のスラッシュは必須なので注意。