[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mhc:00641] Re: High-speed and improved MHC
乃村です。
いい忘れましたが、速いですねぇ。TSU_SPEED
最初、byte-compile 忘れてた。
# RELENG_00 ってそのままじゃ、bytecompile できないのね。:-)
# 知らなかった。
また、長いです。いや、楽しいもので。。
On Tue, 30 May 2000 20:03:10 +0900,
TSUCHIYA Masatoshi <tsuchiya@xxxxxxxxxxxxxxxxxxxxxxx> said:
> nom> ・ C-cC-c 時の conflict 警告がなくなった。
>
> あれま。えっと、高速化にとりかかったのが大体1ヶ月前で、その時点のコー
> ドでは、警告されないような感じになっていたので、手を抜いてました。ちょっ
> と待ってください。
あれ。これは結構前から入っていた筈なのですが。
00changes.jis によると、去年の 11月です。
> に解決するならば、00/01/01 からの経過日数によって管理するようにすれば
> 良いと思いますが…。
>
> どうしましょうか。負の日付を許容するようにすれば、完璧な一般解になると
> は思いますが。
ええ、どちらでもいいと思います。
> nom> 2038年過ぎまでローン抱えている人にも、辛いかも。:-)
>
> これ、どこが原因で発生しますか? 経過日数は 2038 年くらいでは overflow
> しないと思うんですけど。
C-cg で 2039/05 で error が出ます。多分 decode-time です。
> おっと、設計思想の差ですね。最初、あらゆる条件文が記述できる一般的なヘッ
> ダ設計をやりかけました。しかし、そのようにすると、自由度が上がりすぎて
> しまい、逆に説明しづらくなってしまったように感じたので、わざと自由度を
> 落とした設計にしてあります。
僕もそう思います。もっと高度な記述が欲しいなら、
RFC2445 をそのまま使っています。あれは、人間が書く物じゃない。。
> nom> ヘッダの順番を誰かが書換えても不思議ではありません。
>
> これは、ちょっと状況が想像できないのですが…。
gemcal のような elisp でないクライアントが header を dump する場合、
順番に並べて出力してもらう必要があります。
あと Mew が バッファ上で Header の順番を変えることはよくありますね。
メールの header は順番が代わっても意味を変えないと、
みんなは思っているので、その作法から逸脱すると、あまりいいことは
ないというのが僕の意見です。
# おそらく、ユーザは悪気なく変えるでしょう。
> nom> これは、いい書き方を考えたいです。
>
> 良い提案があれば、それに従います。mhc-parse.el は、push/pop parser で
> 処理できる範囲のヘッダ設計であれば、容易に対応できるように工夫してあり
> ます。
ごめんなさい。いうだけいって、案なしです。
何かいい方法がないか考えているのですが。。
> ただ、ヘッダの設計という観点では、従来の MHC はちょっと分かり難いと思
> います。
>
> 例えば、X-SC-Cond: の処理なんですけれど、
>
> X-SC-Cond: 1st Wed
>
> は、( 第1週 and 水曜日 ) という AND 条件を表すヘッダであるのに対して、
>
> X-SC-Cond: 1 Wed
>
> は、( 第1日 or 水曜日 ) という OR 条件を表すヘッダとなっています。つま
> り、1つのヘッダが、内容によって AND を表したり OR を表したりするという
> 複雑なことを行っているわけです。
これは僕も承知しています。こういう規則が裏にあるというのは、
分かり辛いですよね。でも、規則を知らなくても、理性で正しく書けませんか?
例えば、「五月の第二日曜日」 とかも、
何も考えずに頭から書き下して、正解です。
要するに、現実的には ``第1日 or 水曜日'' などと書きたいことは
希なので、現在の MHC の仕様のままでも、
ユーザが無邪気に書いて失敗することは、ほとんどないと思っています。
多分、本当に書こうとして失敗するのは、13日の金曜日ぐらいでしょう。
それよりも、どういう順番で、どっちに並べるんだっけ?
と迷って失敗する確率の方が高いと、僕は判断しました。
ので、ヘッダの種類を 1つ減らすことを選択しました。
> X-SC-Cond: 1st
> X-SC-Cond: Wed
美しいかもしれませんが、頻出する
X-SC-Cond: 1st Wed
を 2つに分けて書かないといけないのは、苦痛ですし、避けたくないですか?
> ちなみに、拡張版 MHC では、X-SC-Cond: / X-SC-Day: の複数並置を許すよう
> になっていますが、複数の X-SC-Cond: については AND として、
> 複数の X-SC-Day: については OR として解釈するという妥協を行っています。
> そんなわけで、13日の金曜日も指定できます。
>
> X-SC-Cond: 13
> X-SC-Cond: Fri
これはいい考えだと思います。簡単なことは簡単に、
そうでない物は何とか書けるという点で。
> nom> 1 article 1 file でなくて、1 article 1 dir にして、
> nom> 関連ファイルまで全部ぶちこめるようにしてしまう。
> nom> それで、仕事全体を管理できるようにするとか。
> nom> (ある方の意見: これはけっこうありかも)
>
> あの、MH 形式は変更したくない、ということではなかったのでしょうか。
あれ、MH 形式のままのつもりです。。だめですか。
といっても、MH 形式を捨てるかどうかは trade-off の問題です。
> そうか、X-SC-Day: じゃなくて X-SC-Duration: で指定してください。
> TODO が表示される範囲を決定するという意味では、こちらの方が元々のヘッ
> ダの意味に近いと思うんですけど。
>
> # それにプログラム的にも対応しやすい。
なるほど。わかりました。
ただ、このへん、もう少し考え所だと思います。
毎月の月末に発生する TODO とかは、直感的にどう書けばいいのだろう?
とか、
「論文提出」、「カメラレディ提出」 とか、2つの Deadline を
Day: に書きたくなるのが人情かな、とか。。
しかし、そうすると、やっぱり、「会議本番」 も同じファイルに書きたくなって、
こっちは TODO には出したくないので、1つのファイルに
TODO とスケジュールを混在させることになって、X-SC-NEXT:
的になるんですよね。。。
X-SC-NEXT: でばんばん書くようになると。
そうすると、何でも intersect/ に入る率が高くなって、
intersect/ を rescan するのが非常に重くなるんではないかという
危惧が。
slot 切る意味があまりなくなるだろうし、
データ構造根本的に見直さないといけないかもしれません。
むしろ flat な構造にして、違う戦略を考える必要があるのではないかと。
cache のチェックを slot 単位ではなくて、file 単位の粒度にする必
要がありそうですね。
ということで、何となく僕の要求がはっきりしてきました。
1. X-SC-Next: 相当の物は必要。
2. ただし、header の順番を変えられても問題のないような記述にしたい。
3. .schedule もその方式で書くと、特別扱いしなくてすむ。
編集もできるようになる。
4. todo はやっぱり Duration: より Day: や Cond: で指定したい。
かな。1, 2 を満たそうと思うと、
今のを大きく変えないといけないかなぁ。。。
作った当初は X-SC-Day: に一杯書ける時点で勝ちだと思っていたんですが、
なかなかそうはいきませんねぇ。
> nom> 僕は、TODO は、schedule/todo/ を作って
> nom> 管理するつもりでした。Done なスケジュールは、
> nom> Category: を DONE にして DONE な物は、色を変えるか
> nom> 見せないようにする。 場合によっては schedule/done に入れる。
> nom> 常に表示すりゃいいんだから、むしろ簡単ですよね。
> nom> # 腰が思いのは、僕が TODO 使わなから。
>
> その案も考えたんですけど…。例えばですね、学会発表なんかで、準備の
> TODO を登録する場合には、学会のスケジュール管理のファイルと TODO のファ
> イルが一緒の方が分かり良いだろうと思ったものですから。
ごめんなさい。この心が分かりません。
todo/ は、スケジュール的には intersect/ と同じ扱いで、
X-SC-TODO: がある場合は todo に refile されるというだけでは
ダメでしょうか? DONE マークを付けても、スケジュールには影響しないし。
> どうぞ、乃村さんの作業が楽なようになさってください。が、
> mhc-schedule.el の構造も劇的に変っているので、mhc-sch-* に依存するよう
> なコードの場合は、二度手間になりかねないとは思います。
ですね。そのへん、見極めたいと思います。
--
nom # コード書く直前と、書いた直後が一番楽しい。