HelpLine

• ひとつ前のバージョンのREADME.mdからの変更を見たい
• README.mdは3日前からどう変わった?
• package.jsonにcoffeeという名前が入ったのはいつ?
• ここ1週間ぐらい変更されてないファイルは?
• 最近大量に修正したファイルはどれだっけ?

　最初の例について考えてみる。 Gitでは「HEAD^」「HEAD^^」のような表現で昔のコミットを参照できるので

$ git diff HEAD^ README.md

$ git log README.md

$ git diff (ひとつ前のバージョンのコミットID) README.md

　しかしこれはなかなか面倒な話である。 手動でコミットIDを手打ちかコピペしなければならない し、当然ながら git logやgit diffといったコマンドの存在と動作を知っていなければならない。 git logやgit diffはよく使うコマンドなので Gitユーザなら誰でも知っているだろうが、 このような簡単な仕事でもコピペのような面倒な操作が必要なのは嫌である。
　実はGitにはrev-listというコマンドがあり、 編集があったコミットのIDをリストすることができる。 これを利用すると、ひとつ前の編集のコミットIDは

$ git rev-list HEAD -- README.md | head -2 | tail -1

git diff $(git rev-list HEAD -- README.md | head -2 | tail -1) -- README.md

　rev-listの-nオプションを利用すると

git diff $(git rev-list -n 1 HEAD -- README.md)^ -- README.md

　それにしても、このように 無駄知識が大量に必要 だったり 単純な要求の実行が大変 だったりするのは嫌すぎる。 上のような工夫によって、 ひとつ前のバージョンのREADME.mdからの変更は調べられるようになったわけだが、 こういった要求は無限にあるわけで、 そのたびにいろんなGit機能を調べたり思い出したりしなければならないのだろうか。 「README.mdは最後にどこ変えたっけ?」 のような自然な質問を簡単に Gitコマンドに翻訳する方法が欲しい。
　こういった要望に対して最近は人工知能的に解決しようとするアプローチが人気かもしれない。 しかしそのためには高度な自然言語処理が必要で、 ちょっと違った表現を許したり内容を変えたりすることは簡単ではない。 大阪弁で質問できる日が来るとは思えない。 また、「longfilename」のようなものを指定しようとして 「logfile」のように間違って入力しても動くようにするには 単純な予測/補完/誤り修正機能などを使った方が良いだろう。
　逆引き辞典などでは 「ひとつ前のバージョンのファイルとの違いを知る」 のようなエントリはあるかもしれないが、 それを調べた後で「README.md」のような名前を指定してコマンドを起動する必要がある。 こういった二度手間も減らしたいものである。

　Macのヘルプで「時間 セット」と入力しても時間をセットする方法は出てこないし、ヘルプを自分で追加することはできない。

時間をセットする方法がヘルプに書いてあったとしても、 時間を4時にセットするためには自分で「4時」という値を指定してから「時間のセット」機能を実行しなければならない。

　マニュアルやヘルプを書くのは面倒なものである。 システムのドキュメントやマニュアルやヘルプシステムを独立に開発するのは 面倒すぎるし齟齬も起きやすいだろう。 ユーザをサポートするシステムがひとつにまとまっていて、 誰でも情報を足したり修正したりできたら嬉しいだろう。

HelpLineのアプローチ

　HelpLineは、以下のような方針で上のような課題をすべて解決しようというものである。

• ユーザのあらゆる曖昧な表現にマッチするようにヘルプ文字列を正規表現で表現し、 コマンドに変換する
- ExpandHelp(ソース / 論文)を利用
• データをすべてクラウド上に置いて編集可能にすることにより、 誰でもデータを追加/修正できるようにする
- Scrapboxを利用
• ユーザが指定したパラメタはそのまま利用して実行に使う
- ユーザが「4」「時間」などと指定すると「時刻を4時にセットする」のようなものを提案して実行可能にする
• 多少の誤入力を許す

利用例

• $ 2 READMEと入力してからCtrl-Jを押すと 以下のような候補リストが提示される

• カーソルで選択してリターンを押すと実行される

• gemでHelpLineをインストール

  % gem install helpline

• ~/.zshrcに以下の記述を追加

  function run-help() {
     helpline "${BUFFER}" < $TTY
     BUFFER=$(cat /tmp/helpline.cmd)
     CURSOR=${#BUFFER}
     zle redisplay
  }
  zle -N run-help
  bindkey "^j" run-help

実装

• re_expand という正規表現展開ライブラリを利用
• Scrapboxにあらゆる情報を書いておく


• 様々なタスクの説明と実際の操作を組にして記述しておき、 ユーザが与えたキーワードやパラメタにマッチするものを リストして実行可能にする
• 行頭に$がある行でタスクの説明を記述し、行頭に%がある行で実行コマンドを示す
• ファイル名にマッチする引数(e.g. READM)や 数字にマッチする引数(e.g. 2)が指定されると $の行に記述された#{filename}や#{number}に マッチする
• マッチしたときは、マッチした文字列が$1などで参照/展開されてGitコマンド文字列になる
• ワンライナーでは難しい場合は exe の下にヘルパーコマンドを用意して利用する (e.g. githelp-changed) )

考察

• 生活の中ではこういった言い換えをいつも行なっているかもしれない。 たとえば「部屋暗くして」と頼まれたら 部屋の入口にある電灯スイッチを操作するかもしれないが、 この場合は頭の中で 「部屋を暗くする」⇒「電灯を消す」⇒「電灯のスイッチを切る」 という翻訳が行なわれていることになる。 こういうことは生活で非常に多いので 翻訳作業があまり気にならないものなのかもしれないが、 そういう「翻訳」は少ない方が良いのは確かだろう。

注意

• re_expandの実装が富豪的なので 大きなリポジトリだと不具合があるかも
• データが全然足りない... 特にリモートリポジトリ関連のデータは皆無だが、 ローカルだけでも充分複雑なのでとりあえずローカル処理の情報を充実させたい
• 旧版はこちら

関連システム

• AnyCode
• 自然言語キーワードからJavaスニペットを検索する
• copy fileA fileB みたいなキーワードから FileUtil.copyFile(new File(fileA), new File(fileB)) みたいなコード候補を生成する
• 文芸的プログラミング