From 90331514c4234c58247888f039e339e68044f7f7 Mon Sep 17 00:00:00 2001
From: morioka <morioka>
Date: Thu, 21 May 1998 12:21:32 +0000
Subject: [PATCH] Sync up with semi-1_4_5.

---
 Makefile    |    2 +-
 TODO        |   43 ++++++++++++++++++++++++++++++++++++++++---
 semi-def.el |    6 ++----
 3 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index bf79417..fb386d6 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
 # Makefile for WEMI.
 #
 
-VERSION = 1.4.4
+VERSION = 1.4.5
 PACKAGE = wemi
 
 SHELL	= /bin/sh
diff --git a/TODO b/TODO
index c7de264..c3cd0b1 100644
--- a/TODO
+++ b/TODO
@@ -3,13 +3,50 @@
 
 * MIME-View
 
-** Mother entity should modify preview-situation of children
-
 ** 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
diff --git a/semi-def.el b/semi-def.el
index 907fe36..4cce381 100644
--- a/semi-def.el
+++ b/semi-def.el
@@ -98,8 +98,7 @@
 	    point (point)
 	    func (get-text-property (point) 'mime-button-callback)
 	    data (get-text-property (point) 'mime-button-data)
-	    )
-      )
+	    ))
     (save-excursion
       (set-buffer buf)
       (goto-char point)
@@ -178,8 +177,7 @@ FUNCTION.")
 
 (defmacro pgp-function (method)
   "Return function to do service METHOD."
-  `(cadr (assq ,method (symbol-value 'pgp-function-alist)))
-  )
+  `(cadr (assq ,method (symbol-value 'pgp-function-alist))))
 
 (mapcar (function
 	 (lambda (method)
-- 
1.7.10.4