Cue

目次

  • Cue とは
  • 特徴
  • できること
  • 実装上の特徴
  • 欠点
  • 環境、入手方法
  • 歴史

    • Cue とは

     Cue は UNIX 上で動作するメールリーダです。

    emacs を使うわけではありませんが、 見かけ上、mh-e や mew に似ています。

    cue という名前は大昔のテープレコーダにあった頭出しの機能 (review/cue) から取りました。

    特徴

    メールを読むのが軽い

    Cue では大きなメール、大量のメールもすばやく表示し、 ページをぱらぱらめくるような間隔でメールを見られるようにする ということを最大の特徴としています。

    必要になるまで実行を遅らせる

    メールリーダは人間が対話的に使うツールですから、 ひとつの操作に対する反応が 10ms 程度であれば操作上問題ありません。 そのため、あらかじめデータを作っておくことなく、 ひとつの操作に対して表示するべき一画面分のデータだけを 毎回準備するのを基本としています。

    できること

     以下は外部コマンドを使用します。かっこ内は default のコマンド

    実装上の特徴

    表示する部分以外はファイルを読み込まない

    1MB もあるような大きなメールを読み込んでいると、ディスクアクセスだけで 結構時間がかかります。 複数のメールを渡り歩いているときに引っかかったような感じがするのは 操作性が悪いので、表示する部分以外は読み込まないようにしています。

    メールを表示するためには、行の折り返しなどのために、 以下の作業が必要となります。

    cue では最初の画面に表示された部分のみについてこれらの解釈を行っています。 次の画面を表示しようとしたときには、その分についてファイルの読み込みから はじめるわけです。

    これは Summary 表示についても同様です。

    mmap の使用

    mmap というのはディスク上のファイルをメモリであるかのようにアクセスする 方法で、最近の UNIX では shared library の実現のために良く使われています。 この機能を使うと、アプリケーションからは、 ファイルサイズ分のメモリを malloc して、そこにファイル全体を読み込んだのと 同じように見えますが、ずっと効率的です。

    read() というシステムコールは、実際にはアプリケーションが用意した領域に、 カーネルが読み込んだファイルの内容をコピーするのですが、 mmap ではカーネルが持っている内容そのものを参照するため、 コピーが不要になります。

    もうひとつ重要なのは、アプリケーションはいつでもファイル内の任意の データを参照することができますが、実際に参照しにいくまで、 ディスクの内容は読み込まれないことです。

    欠点

    日本語しか扱えない

    もちろん英語は OK ですが、内部表現および表示に EUC を使っているため 同時に複数の言語を扱えません。 解決不能ではありませんが、私は日本語しか読めないので必要性を感じない というのが最大の理由です。。

    search が遅い

    必要になるまでなにもしないというポリシーが最も裏目に出るケースです。

    複数のメールに対する reply がしにくい

    エディタを組み込んでいないため、表示とメール作成が全く独立になって しまっています。

    customize できない

    手が回っていません。 特にキーバインドが問題。

    環境によっては起動が遅い

    Mail フォルダが 4.4BSD 系列のローカルファイルシステムに存在しない場合、 特に階層化フォルダを使っていると起動が遅くなることがあります。 これはフォルダ一覧を作るのに時間がかかっているのです。

    数字だけの directory を作らないことにすれば、 folder.c の folder_list() でそういう check をすることでこれを 改善できます。これも customize 関連です。

    4.4BSD の ufs では readdir しただけでファイル種別がわかるので 遅くならずにすみます。

    巨大な multipart メールの次のメールに行くのが遅い

    'n' キーは「次のパート」なので、次のパートを探すために巨大メールを 全部読み込んでしまいます。 「次のメール」というキーがあれば良いのでしょう。

    環境、入手方法

    動作環境

    mmap がある UNIX でしか動きません。以下で動作確認しています。

    リリース(ソース)

    ftp://onoe2.sm.sony.co.jp/pub/cue/

    CVS repository

    (WIDE member only) 
    	Root	sh.wide.ad.jp:/usr/cvsroot/cue
	Module	cue
	Tag	なし

    歴史
    96/11 mh-e ユーザだったが、multipart mail が増えてきたので mew-1.51 を使い始めた
    98/3
    初めて curses というものを使ってみた
    98/4
    IM は perl を使うので遅いと聞いてずっと避けていたが、 さすがに mew も古さが目立ってきたので、mew-1.93b28 に のりかえてみた。確かに IM も遅いが、mew で 'n' とか 'p' を 押し続けたときの反応のトロさにいらだった。
    せっかく curses が少し使えるようになったので、 メールを見られるようにしてみた
    98/5
    普通の curses では日本語が化けるので、 簡単な日本語 curses を書いてみた
    自分で使い始めた (cue 0.1)
    かずに mew が遅いと文句を言ってみた(4倍早くなったそうな)。 cue 0.1 も見せてこのくらいにして、と言ってみたけど、 Multipart 対応してなきゃ早いのは当たり前です、 と言われて終わった。
    Multipart 対応をはじめた
    98/7
    こんな ad hoc な書き方じゃ Multipart 対応できないと きづいて、もう一度最初から書き直しはじめた
    98/8
    cue 0.2 リリース (売り言葉に買い言葉? -- [Mew-dist 05874])
    98/12
    cue 0.3 リリース (直す前に)
    3回くらい書き直したけど面倒臭くなったので、 もいちどもとのをいじり始めた
    99/1
    security の勉強ついでに S/MIME 対応してみた。 (moCA から WWW server の証明書もらうのに S/MIME 署名メールが必要、と言われた)
    cue-0.4 リリース
    multipart の編集を書き直した
    99/2
    Subject: とかに CANNA で直接漢字を入力できるようにしてみた
    help を見えるようにした。
    cue-0.5 リリース
    破綻していた multipart 関係の構造を整理した
    PGP/MIME の暗号化メールが届いたので、PGP/MIME に対応してみた (pgp コマンドは使いにくかったので、いい加減に書いた)
    99/3
    PGP/MIME 暗号化に対応したついでに、S/MIME 暗号化もやってみた
    up onoe@sm.sony.co.jp