--- a/Todo	Fri Jan 01 00:06:23 2010 +0900
+++ b/Todo	Sat Jan 02 03:20:23 2010 +0900
@@ -1,3 +1,62 @@
+Sat Jan  2 00:02:41 JST 2010
+
+Todo:
+    writeLog に level/flag を付けるか?
+
+Selector.select() のフラグは意味がない。その後、必ず、
+selectedKeys() を調べる必要がある。これは、Simulator
+と実ソケットの動作が異なる部分。Warning とか出せないものか?
+
+確かに、Merge 変かも。unMerged を undo するのは良いが、
+sort するのは、unMerged であって、undo を付加したものではないはず。
+
+いや、それは正しく出来ている。output に先にundoを入れて、
+cmd には、そのまま残している。(順序は sort されるので関係ない)
+
+でも、sortedCmds1 に add する時に、Comparator で順序付けされて
+しまう。getPrecedence() は必要な列の切出しに使う。
+
+Self Merge case
+    E_{00} E_{12} E_{01} E_{23} E_{02} (E_{00})
+Other Merge case
+    E_{10} E_{11} E_{23} E_{01} E_{02} (Eack_{10})
+
+ack が間に入ることはない(merge で消されるから)
+original command の存在しない ack もない。
+    (あったら、エラー。無視して良い)
+ack の来ない original command は sequence エラーとなるなず。
+    (あるいは time out)
+
+ということは、getPrecedence せずに、うむを言わせず
+全部 sort すれば良いってこと? ってことは実は、E_{12}
+が来た段階で追い越せるかどうかはわかる?
+
+Ack を受け取ったら、それは、必ず先頭にあるはず。
+
+    E_{00} E_{10} E_{11} E_{23} E_{01} E_{02} (Eack_{10})
+
+とかはない。ack は追い越せないから。この間の入力は確定で、
+優先順位にしたがって順序付しsortする。次は、
+
+           E_{10} E_{11} E_{23} E_{01} E_{02} (Eack_{10})
+                  E_{11} E_{23} E_{01} E_{02} E_{12} (Eack_{11})
+
+で、これは、E_{12} までをsort すれば良い。ということは、
+取れるのは最初の一個だけってこと。
+
+nop の場合は、command が着いた直後に出力されるけど、
+ack の場合は、それは出力されないで、もう一周する
+ack が流される。ack は、一つ前のエディタが出力した
+nop に相当する。
+
+この方法だと、編集コマンドの干渉を気にする必要はない。それは、
+最適化フェーズで自動的に排除される。(はず) ということは、
+getPrecedece の方で sort してやって、今の lineno の比較は
+無意味なので排除ということですね。
+
+2方向をスター型/木型に順々に処理する方法でも良いのか。
+
+
 Wed Nov 26 15:15:16 JST 2008
 
 Ring 構造なので、一部のeidtorで止まると全体が止まってしまう。