From: morioka Date: Thu, 21 May 1998 12:21:32 +0000 (+0000) Subject: Sync up with semi-1_4_5. X-Git-Tag: wemi-1_4_5~3 X-Git-Url: http://git.chise.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=90331514c4234c58247888f039e339e68044f7f7;p=elisp%2Fsemi.git Sync up with semi-1_4_5. --- 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)