[Mew-dist 15451] Re: incremental search in summary mode

[Shun-ichi GOTO]

>>>>> at Wed, 13 Dec 2000 19:19:27 +0900
>>>>> kazu == Kazu Yamamoto (山本和彦) <kazu at example.com> said,

> 別案。
> いっそのこと、thread モードと同様にobarrayとして保持し、.mew-cache
> とは別に保持する。

kazu> 子や兄弟はどうやって探すんですか？

現状のthread 用DBでベクタに保持している情報にメッセージ番号のスロットを
追加してやれば、以下のような感じの手順になると思います。

子を探す  (自分 の子)

1. Summary 上の現在のメッセージ番号のメッセージIDを取得
2. メッセージIDから情報を引き、子のメッセージID(複数)を取得
3. それらのメッセージID(複数)から子のメッセージ番号(複数)を取得
4. それらのメッセージ番号からregexp を作成
5. 前方あるいは後方に検索して移動

兄弟を探す (自分の親 の子)

1. Summary 上の現在のメッセージ番号のメッセージIDを取得
2. メッセージIDから情報を引き、親のメッセージIDを取得
3. 親のメッセージIDから情報を引き、親の子のメッセージID(複数)を取得
4. それらのメッセージID(複数)からメッセージ番号(複数)を取得
5. それらのメッセージ番号からregexp を作成
6. 前方あるいは後方に検索して移動



P.S.
ちなみに私のところの MUE では、Message-Id:からintern したシンボルが情報
を保持するのではなく、message-id からintern したシンボル(ex. (intern
(concat "M" msg-id-str) db)) と、メッセージ番号からintern したシンボル
(ex. (intern (format "#%d" number) db))の2つでリンクを張り合っています。

前者は
『 そのメッセージIDを、Message-Id: として持つメッセージ番号シンボルのリ
   スト(すなわち自分とduplicated な分身)』
と
『 そのメッセージIDを、親のMessage-Id:とするメッセージ番号シンボルのリス
   ト(すなわち子供)』
のcons を保持します

後者は Mew のベクタによる情報構造体と同様、必要な情報を保持します。
ただし、保持するのは自分自身のMessage-Id: と 親メッセージのMessage-Id: 
のみで、それぞれシンボルとしてベクタに納められます。

メッセージIDシンボルが情報ベクタを保持しないのは、
同一Message-Id: を持つ複数のメッセージが存在するから。

シンボルを介して互いにリンクし合うようにしているのは、
番号から情報を引きたい時と、message-id から引きたい時と両方が
それなりの頻度を持っていたため、こうしたのだったと思った(もう動機は忘れた)
あと深いリスト構造を使いたくなかった事と、リストの循環をさせたくなかった
辺りもあったような...

## この構造は決して吟味の末のものではない事をお断りしておきます。(^^;


P.P.S

現在のMew がメッセージの情報をもっとたくさん持つ事があり得そう(例えば日
付の例が既に挙がっていますよね)ならば、selective-display を捨ててdb に
よる保持に移行するのは必須かな、と思います。

しかし、これに手を出すと再現が無くなり、元のシンプルさ、軽快さからはなれ
ていく事が予想されます。現在の(少なくともこれまでの)Mew は、Summary さえ
作ってしまえばあとは.mew-cache をバッファに読む時間を待つだけであとはサ
クサク動く、という大きな利点があり、それが特徴でもあったわけですので、
db の話はなかなか難しいところ...


--- Regards,
 Shun-ichi Goto  <gotoh at example.com>
   R&D Group, TAIYO Corp., Tokyo, JAPAN