file i/o #4

ex コマンド read コマンドは動くようになった。
内部の動作ではなく、操作の流れを主体にすると以下のようになる:

  1. :r file nameと入力
  2. 別タブで dropbox 上のページが開き、api へのアクセスの許可を求められる
  3. 許可する。ページは自動的に閉じ、wasavi を開いているタブが再度アクティブになる
  4. ファイルが読み込まれるまで待つ。認可のフェーズが進むごと、あるいは読み込みが適当に進むごとにステータスライン上の進捗メッセージが更新される
  5. 読み込まれる

もちろん、一度認可を済ませていればあとはまったくローカルで vi を動かしているかのように read コマンドは振る舞う。まあさすがに dropbox からの読み込みは一瞬とは行かないが……。

さて read コマンドは、ファイルアクセス系のコマンドの中でもかなり単純な部類で、本質的にはファイルシステムからのペーストみたいなものだ。ただ以下のことを考える必要はある:

  • 改行コード。今更言うまでもないが、\r と \n と \r\n 系がある。\r は OS X より前の Mac OS だろうから対応する意味はないかもしれない。行ごとの読み込み時の改行コードを覚えておいて書き出し時にはそれを再利用するのと、新規に行を挿入する場合は読み込み時に最も多かった改行コードを用いる、あたりがポイントか? もっと単純に単体のファイルには 1 種類の改行コードのみが使われると決め打ちしてもいいかな
  • エンコーディング。世の趨勢、特に web 系は UTF-8 固定でいいじゃんという感じになりつつあるようなないような感じだが、まだ他のエンコーディングを一切考えなくてもよいというわけでもない。でも javascript でエンコード変換って重いしテーブルはでかいしどうもなー。appsweets.net 上に適当なプロクシサービスを置いてそれを利用するか? しかしそういったプロクシを通すなら、そもそも OAuth の処理自体もサーバでやったほうがいいじゃんという気も……

それはそれとして、読み込みの次の段階は edit コマンドだ。こちらは read に比べるとなかなか手ごわい。

e[dit][!][+command][file]
コマンド名に「!」が追加されておらず、かつバッファが変更済みの場合、エラーになる。

file が指定されている場合、バッファの内容は file の内容で置き換えられ、file のパス名がバッファに関連付けられる。file が指定されていない場合、バッファの内容はバッファに関連付けられたパス名の最新の内容で置き換えられる。何らかの理由で file の内容にアクセスできない場合、バッファは空になる。

+command オプションは空白で区切られる。+command 内の空白文字はバックスラッシュを前置することでエスケープできる。+command はバッファの内容が置き換えられ、現在行と現在桁がセットされた直後に ex コマンドとして実行される。

現在行と現在桁は以下のようになる:

  • バッファの内容が空である場合:
    現在行は 0 になる
    現在桁は 1 になる
  • そうではなく、ex コマンドモードで実行されたか、もしくは +command 引数が指定されている場合:
    現在行はバッファの最終行になる
    現在桁は最初の非空白文字になる
  • そうではなく、file が省略され、現在のパス名が用いられた場合:
    現在行はバッファの先頭行になる
    現在桁は最初の非空白文字になる
  • そうではなく、file が以前に編集されたファイル名の場合:
    現在行は最後に編集した位置を覚えていればその位置になる。覚えていないかその値がバッファの新しい内容において不正である場合は、バッファの先頭行になる
    現在桁は最後に編集した位置を覚えていればその位置になる。覚えていないかその値がバッファの新しい内容において不正である場合は、最初の非空白文字になる
  • そうではない場合:
    現在行はバッファの先頭行になる
    現在桁は最初の非空白文字になる

Leave a Reply

Your email address will not be published. Required fields are marked *