モジュール

再利用性とかを考えて次の3ブロックにわける

字句解析

* モジュール名 ttycode * API

read

struct tty_code* ttycode_read(FILE* fi);

読み込み元をFILE構造体にするかどうかはもう少し考える案としては以下のものも考えている

1.

struct tty_code* ttycode_read(unsigned long(*tty_fread)());

1.

ttyFILE ttycode_open("file");
struct ttycode* ttycode_read(ttyFILE*);
ttycode_close(ttyFILE*);

端末設定

ttyを設定 (他の形ないかな)

int ttycode_setty(char*);

* 構造体データを読み込み以下のような構造体で結果を返す (defineはもうちょっと考える)

struct ttycode {
  int type;
#define TTY_CODE_CHAR 0   // 文字
#define TTY_CODE_SAVE 1   // saveキー
  :
  :
#define TTY_CODE_XOFF 100 // XOFFキー
  union {
    unsigned long char;   // utf8で格納
    long attr[10];        // 属性(10に意味は無い。。。)
  } data;
};

* その他 ncurses、screenからぱくれるコードを検討

端末表現

* モジュール名 tty * api

読み込み元設定
```
tty_open(FILE*);
```

複数オープンできるようにリソースハンドルを作るべき？

端末保持データ取得
```
struct tty_buffer* tty_read();
```
閉じる
```
tty_close();
```

* 構造体

struct tty_buffer {
  char marker;               // 点滅とか下線とか
  char color;                // 色
  char scr_num;              // 画面上にあるか、何番目の画面メモリにあるか(画面が0)
  unsigned long char;        // 文字
  struct tty_buffer* befor;  // 前の行の先頭文字の構造体
  struct tty_buffer* next;   // 次の行の先頭文字の構造体
};

* その他構造体は今後の端末に対する自分の理解によりどんどん変わっていく
端末のサイズ変更などのAPIを追加する必要あり
すべての情報をメモリに持っておくためマシンによっては動かない。古いマシンを切り捨てるかハードな使い方をする人を救うかは今後の課題

出力

* モジュール名 tty2txt * API 用意しないただし内部関数として以下の関数を想定

tty2txt(char*); // ファイル名を引数に渡す。ただしファイル名が"-"の場合標準入力

その他

ドキュメントはどうやって管理するか。過去10年の経験でソースコードに埋め込んでも(javadocのような方法)やっぱり忙しいとソースとの乖離が発生するのは経験済みorz
ソース管理はsvn。ただしsvnのブランチ、タグの表現方法は何かしっくり来ないので検討が必要。履歴管理は１００点だと思う。