TODO

   1 [TODO]
   2 ======
   3
   4 * MIME-View
   5
   6 ** dynamic configuration for 'mime-preview-condition
   7
   8 ** multipart/related support
   9
  10 ** Don't use filter-model
  11
  12   tomo (major developer of SEMI) and akr (major developer of
  13 FLIM-FLAM) discussed about Emacs 20.3 problem related with SEMI and
  14 FLIM.  They found essential problem with Emacs 20.3 are:
  15
  16   - Emacs 20.3 separates string-type to unibyte-string and
  17     multibyte-string.  Emacs 20.3 has enough APIs to treat them.
  18
  19   - Buffer has mode about interpretation of contents.  Each mode is
  20     designed to save semantics as characters.  Namely buffer contains
  21     unibyte-characters or multibyte-characters.  One buffer can not
  22     contain both representations.
  23
  24   - {decode|encode}-coding-{region|string} run in byte world.  So it
  25     is not harmonized with other API.
  26
  27   - It seems easy to write code in one mode or one world
  28     (unibyte-string or multibyte-string).  However it seems not easy
  29     to write inter-mode program, such as SEMI.
  30
  31   - Byte <-> byte conversion, such as base64, quoted-printable, must
  32     be run only with unibyte-mode.
  33
  34   - Byte <-> character conversion, such as
  35     {decode|encode}-coding-region, should not be defined in single
  36     buffer.  Instead of them, decoder should read from unibyte buffer
  37     and output to multibyte buffer.  Similarly, encoder should read
  38     from multibyte buffer and output to unibyte buffer.
  39     `insert-buffer-substring' like API may be suitable.  Anyway Emacs
  40     introduces multiple representations, so it should be redesigned
  41     based on multiple representation world model.
  42
  43   Anyway FLIM should introduce new APIs based on inter-representation
  44 world model.  Conventional APIs should be implemented based on new
  45 APIs.
  46
  47   SEMI should abolish filter model and introduce new methods to
  48 display inline data.  These methods should use new FLIM APIs based on
  49 inter-representation world model.
  50
  51
  52 * MIME-Edit
  53
  54 ** WYSIWYG editing support
  55
  56 ** Use MIME-Preview like tag and display
  57
  58 ** Redesign to use two buffers for one message
  59
  60   MIME-View is based on "Multiple Representation Space (layer) Model".
  61 In this model, network representation and its presentation are
  62 distinguished.  Thus MIME-View uses two buffers for one message,
  63 'mime-raw-buffer (for network representation) and
  64 'mime-preview-buffer.  MIME-View manages them based on information of
  65 entities.  According to experience of MIME-View, this model is good to
  66 treat complex structured data, such as MIME.
  67
  68   MIME-Edit was designed to use one buffer for one message.  So it is
  69 hard to edit like WYSIWYG style.  Format of tag is limited by
  70 translation.  Content of forwarded message is unreadable.  It is
  71 better to introduce "Multiple Representation Space Model" to resolve
  72 these problems.
  73
  74 ** Check available MIME-charset
  75
  76     MIME-charset \e$B0J30$,@8@.$5$l$k>l9g$N=hM}$r;XDj$G$-$k$h$&$K$9$k!#\e(B
  77
  78     For example:
  79
  80         (a) translate problematic characters to similar representation
  81         (b) display warning message
  82             (e.g. "`x-ctext' is generated.  Do you send it? (yes/no)")
  83         (c) stop sending
  84
  85 ** Don't use buffer-local variables
  86
  87   Don't use buffer-local variables to control behavior about
  88 translating to network representation, such as 'mime-transfer-level,
  89 'mime-transfer-level-string,
  90 'mime-edit-charset-default-encoding-alist, 'mime-edit-pgp-processing.
  91 Because they have problem with Semi-gnus.
  92
  93
  94 * Etc.
  95
  96 ** Write manual
  97
  98
  99
 100 [Known Bugs]
 101 ============
 102
 103 * MIME-Edit