[mhc:00645] Re: High-speed and improved MHC

[Yoshinari NOMURA <nom@xxxxxxxxxxxxxxxxxxx>]

On Tue, 30 May 2000 23:24:31 +0900,
	TSUCHIYA Masatoshi <tsuchiya@xxxxxxxxxxxxxxxxxxxxxxx> said:

> nom> いい忘れましたが、速いですねぇ。TSU_SPEED
> nom> 最初、byte-compile 忘れてた。
> 
> そりゃあ、全ての面において速度を重視した coding をしてありますから…。

血道っていう意味が分かりますね。

> もっと徹底するなら、X-SC- が省略できることにして、
> 
>     X-SC-Subjcet: 研究会
>     X-SC-Cond: Wed
>     X-SC-Complex: Day: 20000531; Subject: 研究会発表
> 
> という記法を許すことにする。この記法ならば、X-SC-Complex: によってまと
> められていない部分が default を表すと考えれば分かりやすそうです。例え
> ば、
> 
>     X-SC-Subjcet: 班別会議
>     X-SC-Cond: Thu
>     X-SC-Location: 大会議室
>     X-SC-Complex: Day: 20000601; Location: 第2会議室
> 
> というような書き方が出来るでしょう。

僕も、帰りの車の中で同じような事を考えてました。1つの解だと思います。

>     X-SC-Sexp: (if (day 20000531) (subject "研究会発表"))
> 
> ‥‥というのはやり過ぎですね。

実は、このやり過ぎもありかなと思っています。
Sexp は、elisp に寄り過ぎるので、適切な文法を定義してやるのはどうでしょう。

これしかないのはやりすぎですが。MHC の元々のヘッダで、ほとんどの
場合 OK なはずです。となると、第二の方法を使うのは、
かなり複雑なのを書きたいときです。どうせなら万能を目指すというのも
1つの方法です。calendar.el とかも、そうじゃなかったっけ。

実際の所、他の人は、どんなデータが MHC では記述できずに困ってい
るのか調査したい所ですね。僕が書きたいのは、公務員の給料日。

・基本的に毎月 17日だが、17日が休日の場合は 16, 15 ..
  と手前にずれる。でも 3日以上は手前にずれないで、
  その場合は、18, 19 .. と後方の平日に向かってずれる。

これが書ける能力が欲しいです。

あと、ありがちで書けないのは、

・ 2週に 1回の木曜日。ただし、年末年始は除く。

他に何かありませんか。
春分、秋分もこれで書けるなら、列挙する方針を変えます。

> 土> つまり、1つのヘッダが、内容によって AND を表したり OR を表したりする
> 土> という複雑なことを行っているわけです。
> 
> nom> これは僕も承知しています。こういう規則が裏にあるというのは、
> nom> 分かり辛いですよね。でも、規則を知らなくても、理性で正しく書けませんか?
> 
> 同意します。parser を書くのは面倒でしたが…。

> nom> 美しいかもしれませんが、頻出する
> nom> X-SC-Cond: 1st Wed 
> nom> を 2つに分けて書かないといけないのは、苦痛ですし、避けたくないですか?
> 
> でしたら、積和標準形に直すのはどうでしょう? つまり、1つのヘッダの中で
> は AND 条件、並置されたヘッダは OR 条件とします。

うーん、そうすると、
  X-SC-Cond: 5 15 25      ;; 「5の付く日」 
  X-SC-Cond: 1st 3rd Wed  ;; 第一第三 水曜日

も比較的よくあるスケジュールだと思うのですが。これのとき困りますよね。

> ただまあ、こうすると予想されるのは、「第1、第3水曜日」という指定が面倒
> じゃないか、ということなんです。

あ、そのとおり。基本的に、決めの問題ですから、
解はいくらでもあるのですが、落とし所の問題ですよね。。

> と、よく考えてみると、X-SC-Duration: が導入されている理由が分からなく
> なってきますね。X-SC-Cond: で指定される他の構文要素と判別可能なので、
> 統一できるのではないでしょうか。

そうですね。そういう意味では、Date: も Cond: とまとめられます。
これは、見た目です。

> えっと、毎月月末に発生するんですか。そういうのはスケジュールに記入して
> 欲しいなぁ…。
> 
> ## 弱気モード。
> 
>     X-SC-Cond: Last
>     X-SC-Subject: 月末決算書の整理
>     X-SC-ToDo: 100
> 
> という指定が出来るのですが、どうでしょう?

なるほど。こういう書き方もあるのか。。

>     X-SC-Duration: 20001201-20001205
>     X-SC-Subject: 1st MHC International Conferenece
>     X-SC-Location: 九大

うーん。まず、Duration: だけではスケジュールを指定したことになら
ない仕様です。ので、現行の MHC 的には、これは空のスケジュールです。

>     X-SC-Next:
>     X-SC-Duration: 20000601-20000630
>     X-SC-Subject: 論文執筆
>     X-SC-ToDo: 100
>     X-SC-Next:
>     X-SC-Day: 200000630
>     X-SC-Subject: 論文提出
>     X-SC-Next:
>     X-SC-Duration: 20000901-20000930
>     X-SC-Subject: カメラレディ準備
>     X-SC-ToDo: 100
>     X-SC-Next:
>     X-SC-Day: 20000930
>     X-SC-Subject: カメラレディ提出
> 
> というのでは、十分に直感的ではないでしょうか。こうすると、スケジュール
> 帳に締切日が表示されるのと同時に、下の TODO リストにも表示されるように
> なるんですけど。

僕ならですね。

X-SC-Day: 20001201-20001205  ;; これは、便宜上の嘘ね。
X-SC-Subject: 1st MHC International Conferenece
X-SC-Location: 九大
X-SC-Next:
X-SC-Day: 20000630
X-SC-Subject: 論文提出締切
X-SC-ToDo: 100
X-SC-Next:
X-SC-Day: 20000930
X-SC-Subject: カメラレディ締切
X-SC-ToDo: 100

と書きたい。こう書くと、TODO の表示欄には、常に DONE になるまで
表示していてほしい。

1年後に締切があるような TODO をどこに置くかということになりますが、
土屋さんの意見は、 Duration: で 1年後を指定しといて、
intersect/ に入れようということですね。それとは別に、
締切をスケジュールにも出したい場合は、Next: でもう1個書くということですね。
それって、1個記事が増えるだけで、嬉しくなくないですか。

普通締切のある TODO はスケジュールに載せたいでしょう?
締切がない場合は、書かないから schedule にも出ないので、
ハッピーだと思うんですけど。

> MHC の内部では、file 単位での cache 制御が有効になっています。gemcal 
> などの外部プログラムと連携する場合に限って、slot が作り直されます。
:
> はい、編集できるようにはしていませんが、私の手元では既に X-SC-Next: を
> 使って書き直したものを使っています。このように変更すると、更に速くなり
> ます。
> 
> その気になれば、~/.schedule を捨てて、schedule/intersect/ 下の一般スケ
> ジュールファイルの1つとして扱うことも可能です。

なるほど。このへん、いい感じですね。

> 誤解させてしまいましたが、上述のように Day: も Cond: も使えます。しか
> し、
> 
>     X-SC-Day: 20000531
>     X-SC-ToDo: 1
> 
> という指定をすると、5月31日にスケジュールを確認したときだけ TODO リス
> トに掲載されることになるので、あまり意味がないと思います。
> 
> # X-SC-Day: の意味からすると、これが自然だと思うのですけれど。

うーん、やっぱり TODO のときは、Day: を Deadline として扱うのが
いいのでは? すると、schedule 上にも素直に反映させることができる。
Day: は X day なのです。TODO でいうと、締切。

Duration というのは、ある、スケジュールや TODO の有効範囲をさら
に限定するもので、直接 X day を示すものではないということです。

> いえ、別にそれでも構いませんが、そのようにすると結局 schedule/todo/ に
> ついても schedule/intersect/ と同じように検索をかけなければいけないと
> 言うことには変わりありませんから、ディレクトリが増えるだけで、プログラ
> ム的に嬉しいことはないような気がするのですけれど、どうでしょうか?

いわれてみれば、そうかもしれない気がしてきました。。

refile 先の計算が簡便になるというメリットと、
TODO 分けとくと、締切のなしスケジュールを一杯いれる人に
にはいいかなという気がしてたのですが。

あと、mh の scan だけで TODO リストが見れたりして嬉しいかなと。
--
nom