[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mhc:00640] Re: High-speed and improved MHC
>> On Tue, 30 May 2000 18:30:59 +0900
>> "nom" == nom@xxxxxxxxxxxxxxxxxxx (Yoshinari Nomura) said as follows:
nom> 使ってみました。
nom> C-cC-c 時のチェックは、まだ入れていないからだと思いますが、
[...]
nom> 等々、1回も起こらないような指定すると迷子になりますね。
そうです。現時点では、header syntax error についてはチェックされますが、
ご指摘のような意味論的な error についてはチェックしていません。
もっときちんとするためには、parse error の発生した場所と、発生原因を通
知するようにするべきだと思いますが、TODO ってことで。
nom> ・ C-cC-c 時の conflict 警告がなくなった。
あれま。えっと、高速化にとりかかったのが大体1ヶ月前で、その時点のコー
ドでは、警告されないような感じになっていたので、手を抜いてました。ちょっ
と待ってください。
nom> ・ X-SC-Cond: Sun なるスケジュールを C-cd すると、
nom> One or All と聞かないで、いきなり全部消してしまう。
これは (mhc-logic-occur-multiple-p) のバグですね。ちょっとややこしいの
で、時間を下さい。
nom> ・ X-SC-Day: 20000530 なるスケジュールを毎週に変更したくて
nom> C-cm で X-SC-Cond: Tue として C-cC-c したら、エラーになった。
修正しました。
nom> ・ Refile ? に 'n'' と答えると、完全にドラフトまで消える
修正しました。
nom> ・ アポロ 11号の月着陸 (1969/7/20) が入力できない。
それは日付を 1970/01/01 からの経過日数で管理しているからですね。adhoc
に解決するならば、00/01/01 からの経過日数によって管理するようにすれば
良いと思いますが…。
どうしましょうか。負の日付を許容するようにすれば、完璧な一般解になると
は思いますが。
nom> 2038年過ぎまでローン抱えている人にも、辛いかも。:-)
これ、どこが原因で発生しますか? 経過日数は 2038 年くらいでは overflow
しないと思うんですけど。
nom> ・ X-SC-Day: 20000530 なのを消すと、schedule/trash じゃなくて、
nom> schedule/2000/05/trash を掘ってしまう。
従来版の仕様を勘違いして実装してました。修正しました。
nom> ・ TODO は先頭にあった方がいいかな。
nom> 3ヶ月縦カレンダーの上か下が一番いいけど。
これは、以下のようなオプションを新設するのが良いと思っています。
(mhc-defcustom mhc-todo-position nil
"Variable to specify position of TODO list."
:group 'mhc
:type '(radio (const :tag "Bottom" nil)
(const :tag "Top" t)
(const :tag "Above of vertical calender" 'above)
(const :tag "Below of vertical calender" 'below)))
ただ、この部分はユーザーの好み次第なので、場所についての希望が出揃って
から実装しようと思っていました。
nom> ・ X-SC-Next: はヘッダの順序を規定してしまうので、ちょっと嫌かも。
おっと、設計思想の差ですね。最初、あらゆる条件文が記述できる一般的なヘッ
ダ設計をやりかけました。しかし、そのようにすると、自由度が上がりすぎて
しまい、逆に説明しづらくなってしまったように感じたので、わざと自由度を
落とした設計にしてあります。
例なんですけど、
X-SC-Subject: 研究会
X-SC-Cond: Wed
X-SC-Location: 大会議室
X-SC-Next:
X-SC-Day: 20000531
X-SC-Subject: 研究会発表
という場合、2つ目の部分では場所指定が省略されているわけですけど、これ
は1つ目の部分の値を default として使うようにして欲しい。で、default 値
として使われるのが、何処になるのかということを分かりやすく指定するため
には、自由度を落として、ヘッダの順序に依存するような書き方に制限してお
いた方が良いだろう、と考えました。
nom> ヘッダの順番を誰かが書換えても不思議ではありません。
これは、ちょっと状況が想像できないのですが…。
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 条件とし、AND
の場合は複数に分けて書く』というような和積標準形とした方が分かりやすい
と思うのですが。
X-SC-Cond: 1st
X-SC-Cond: Wed
ちなみに、拡張版 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> 例えば、yyyymmdd+HH:MM-HH:MM のように HH:MM-HH:MM
nom> がある日に限って、X-SC-Time: より + 以降を優先するとかはどうで
nom> しょうか。(確か大原さんの案。)
nom> しかし Location (当時はなかった?) まで扱えるようにするには、
nom> もうちょっと考えないといけないですね。
私の最初の考えでは、X-SC-Begin: / X-SC-End: という2つのヘッダを導入し
て、ヘッダをブロック化できるようにすることを構想していました。
nom> MIME の Multipart にして繋げるとか。(おおげさ?)
SEMI / FLIM に依存するようにするならば、それなりに容易に実装できそうな
気もしますが、Mew に対応するためには、それでは困るのではないでしょうか?
nom> 1 article 1 file でなくて、1 article 1 dir にして、
nom> 関連ファイルまで全部ぶちこめるようにしてしまう。
nom> それで、仕事全体を管理できるようにするとか。
nom> (ある方の意見: これはけっこうありかも)
あの、MH 形式は変更したくない、ということではなかったのでしょうか。
nom> ・ ToDo は、ずっと先の締切まで含めて、全部見たいのでは?
nom> 今の実装だと今月締切の物しか出ないですよね。
nom> (というか、今のところ Date: 入れちゃいけない?)
いえ、そんなことはないはずです。私の例だと、
X-SC-TODO: 100
X-SC-Duration: -20000801
X-SC-Subject: 投稿締め切り
なんていう TODO を登録して使っています。
そうか、X-SC-Day: じゃなくて X-SC-Duration: で指定してください。
TODO が表示される範囲を決定するという意味では、こちらの方が元々のヘッ
ダの意味に近いと思うんですけど。
# それにプログラム的にも対応しやすい。
nom> 僕は、TODO は、schedule/todo/ を作って
nom> 管理するつもりでした。Done なスケジュールは、
nom> Category: を DONE にして DONE な物は、色を変えるか
nom> 見せないようにする。 場合によっては schedule/done に入れる。
nom> 常に表示すりゃいいんだから、むしろ簡単ですよね。
nom> # 腰が思いのは、僕が TODO 使わなから。
その案も考えたんですけど…。例えばですね、学会発表なんかで、準備の
TODO を登録する場合には、学会のスケジュール管理のファイルと TODO のファ
イルが一緒の方が分かり良いだろうと思ったものですから。
nom> それと、Record-Id とのマッピングを考えると、ディレクトリは flat
nom> な方がいいのかなとかも考えてしまいますね。
うーん。
# 内部構造としては劇的に変化していますが、データ構造まではいじる気はな
# かったので…。
nom> Alarm のコードを入れたいんですが、
nom> その前に TSU_SPEED のデータ構造を入れた後にするか前にするかは、
nom> コード見て判断させて下さい。
どうぞ、乃村さんの作業が楽なようになさってください。が、
mhc-schedule.el の構造も劇的に変っているので、mhc-sch-* に依存するよう
なコードの場合は、二度手間になりかねないとは思います。
nom> あ、そう。cahce するときに lisp 式そのものをファイルに書き出すと
nom> 立ち上げが格段に速くなると思うんですが。
そうですね、slot 単位でファイルに書き出しておくと良いかもしれません。
nom> .schedule の parse に時間がかかっているはずで、しかもほとん
nom> ど更新されないので。
~/.schedule の解析って、割合的には、それほど時間かかっていないようです。
手元での手抜きな測定では、
Function Name Call Count Elapsed Time Average Time
============================== ========== ============ ============
mhc-scan-month 1 0.953851 0.953851
mhc-slot-get-constant-schedule 9 0.4700899999 0.0522322222
となっているので。
# 評価用S式を byte-compile もしているので、初回起動時にはどうしても時
# 間がかかります。
nom> それと、デバッグ用に chace を全部 clear する interactive
nom> なコマンドが欲しいです。(current でいう所の mhc-clear-chache)
M-x mhc-slot-clear-cache でクリアできます。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/