TODO

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