X-Git-Url: http://git.chise.org/gitweb/?a=blobdiff_plain;f=TODO;h=c3cd0b122f7e30af451555aa4e9b4f6fd39343fa;hb=bf765ed3ff2c3d2546f0687131812b307f9bd041;hp=85171d16957a3fb73d385634c971188b299d1223;hpb=1838252ff121ea3ccd7cf0f6cad68ac11660ae86;p=elisp%2Fsemi.git

diff --git a/TODO b/TODO
index 85171d1..c3cd0b1 100644
--- a/TODO
+++ b/TODO
@@ -1,12 +1,52 @@
-* MIME-View
+[TODO]
+======
 
-** Mother entity should modify preview-situation of children
+* MIME-View
 
 ** Better implementation for multipart/alternative
  
 ** dynamic configuration for 'mime-preview-condition
 
-** Fix problem of dynamic configuration for 'mime-acting-condition
+** Don't use filter-model
+
+  tomo (major developer of SEMI) and akr (major developer of
+FLIM-FLAM) discussed about Emacs 20.3 problem related with SEMI and
+FLIM.  They found essential problem with Emacs 20.3 are:
+
+  - Emacs 20.3 separates string-type to unibyte-string and
+    multibyte-string.  Emacs 20.3 has enough APIs to treat them.
+
+  - Buffer has mode about interpretation of contents.  Each mode is
+    designed to save semantics as characters.  Namely buffer contains
+    unibyte-characters or multibyte-characters.  One buffer can not
+    contain both representations.
+
+  - {decode|encode}-coding-{region|string} run in byte world.  So it
+    is not harmonized with other API.
+
+  - It seems easy to write code in one mode or one world
+    (unibyte-string or multibyte-string).  However it seems not easy
+    to write inter-mode program, such as SEMI.
+
+  - Byte <-> byte conversion, such as base64, quoted-printable, must
+    be run only with unibyte-mode.
+
+  - Byte <-> character conversion, such as
+    {decode|encode}-coding-region, should not be defined in single
+    buffer.  Instead of them, decoder should read from unibyte buffer
+    and output to multibyte buffer.  Similarly, encoder should read
+    from multibyte buffer and output to unibyte buffer.
+    `insert-buffer-substring' like API may be suitable.  Anyway Emacs
+    introduces multiple representations, so it should be redesigned
+    based on multiple representation world model.
+
+  Anyway FLIM should introduce new APIs based on inter-representation
+world model.  Conventional APIs should be implemented based on new
+APIs.
+
+  SEMI should abolish filter model and introduce new methods to
+display inline data.  These methods should use new FLIM APIs based on
+inter-representation world model.
 
 
 * MIME-Edit
@@ -15,6 +55,22 @@
 
 ** Use MIME-Preview like tag and display
 
+** Redesign to use two buffers for one message
+
+  MIME-View is based on "Multiple Representation Space (layer) Model".
+In this model, network representation and its presentation are
+distinguished.  Thus MIME-View uses two buffers for one message,
+'mime-raw-buffer (for network representation) and
+'mime-preview-buffer.  MIME-View manages them based on information of
+entities.  According to experience of MIME-View, this model is good to
+treat complex structured data, such as MIME.
+
+  MIME-Edit was designed to use one buffer for one message.  So it is
+hard to edit like WYSIWYG style.  Format of tag is limited by
+translation.  Content of forwarded message is unreadable.  It is
+better to introduce "Multiple Representation Space Model" to resolve
+these problems.
+
 ** Check available MIME-charset
 
     MIME-charset 以外が生成される場合の処理を指定できるようにする。
@@ -25,3 +81,23 @@
 	(b) display warning message
 	    (e.g. "`x-ctext' is generated.  Do you send it? (yes/no)")
 	(c) stop sending
+
+** Don't use buffer-local variables
+
+  Don't use buffer-local variables to control behavior about
+translating to network representation, such as 'mime-transfer-level,
+'mime-transfer-level-string,
+'mime-edit-charset-default-encoding-alist, 'mime-edit-pgp-processing.
+Because they have problem with Semi-gnus.
+
+
+* Etc.
+
+** Write manual
+
+
+
+[Known Bugs]
+============
+
+* MIME-Edit