+[TODO]
+======
+
* MIME-View
-** Unify entity display specifications to 'mime-preview-condition
+** dynamic configuration for 'mime-preview-condition
+
+** multipart/related support
-** Mother entity should modify preview-situation of children
+** Don't use filter-model
-** Better implementation for multipart/alternative
-
-** Change 'mime-acting-condition to condition-tree format
+ 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:
-** dynamic configuration for 'mime-preview-condition
+ - 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.
-** mailcap support
+ - Byte <-> byte conversion, such as base64, quoted-printable, must
+ be run only with unibyte-mode.
-** dynamic configuration for 'mime-acting-condition
+ - 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
** Use MIME-Preview like tag and display
-** keymap-prefix
+** 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 \e$B0J30$,@8@.$5$l$k>l9g$N=hM}$r;XDj$G$-$k$h$&$K$9$k!#\e(B
+
+ For example:
+
+ (a) translate problematic characters to similar representation
+ (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
+
+** Content-ID is mandatory for message/external-body
projects / elisp / semi.git / blobdiff