From taka ＠ kawate.net  Tue Jan  4 18:22:45 2000
From: taka ＠ kawate.net (Takayoshi TK KAWATE)
Date: Tue, 04 Jan 2000 18:22:45 +0900 (JST)
Subject: 無題
Message-ID: <20000104.182245.64529179.taka@kawate.net>

subscribe Takayoshi KAWATE



From keiichi ＠ nanap.org  Tue Jan  4 19:11:53 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 04 Jan 2000 19:11:53 +0900
Subject: none
In-Reply-To: <20000104.182245.64529179.taka@kawate.net> (Takayoshi "TK" KAWATE's message of "Tue, 04 Jan 2000 18:22:45 +0900 (JST)")
References: <20000104.182245.64529179.taka@kawate.net>
Message-ID: <uvh5am9hy.fsf@kei.nanap.org>

;; 突然のメイル失礼します、鈴木圭一と申します。

>>>>> emacs-mime-ja の No. 00296
>>>>> Message-Id: <20000104.182245.64529179.taka ＠ kawate.net> で、
>>>>> "TK" == Takayoshi "TK" KAWATE <taka ＠ kawate.net>さま曰く...

TK> subscribe Takayoshi KAWATE

X-ML-Info: If you have a question, send a mail with the body
	"help" (without quotes) to the address emacs-mime-ja-ctl ＠ m17n.org;
	help=<mailto:emacs-mime-ja-ctl ＠ m17n.org?body=help>

...だそうです。

ご参考までに。

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From keiichi ＠ nanap.org  Tue Jan  4 19:19:06 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 04 Jan 2000 19:19:06 +0900
Subject: none
In-Reply-To: <uvh5am9hy.fsf@kei.nanap.org> (Keiichi Suzuki's message of "04 Jan 2000 19:11:53 +0900")
References: <20000104.182245.64529179.taka@kawate.net>
 <uvh5am9hy.fsf@kei.nanap.org>
Message-ID: <uso0em95x.fsf@kei.nanap.org>

>>>>> emacs-mime-ja の No. 00297
>>>>> Message-Id: <uvh5am9hy.fsf ＠ kei.nanap.org> で、
>>>>> "圭一" == 私は書きました。

圭一> ...だそうです。

すみません、直接送ろうと思っていたのに、 ML の方に投げてしまいました。 ^^;;;

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From taka ＠ kawate.net  Tue Jan  4 20:11:37 2000
From: taka ＠ kawate.net (Takayoshi TK KAWATE)
Date: Tue, 04 Jan 2000 20:11:37 +0900 (JST)
Subject: none
In-Reply-To: <uso0em95x.fsf@kei.nanap.org>
References: <20000104.182245.64529179.taka@kawate.net>
	<uvh5am9hy.fsf@kei.nanap.org>
	<uso0em95x.fsf@kei.nanap.org>
Message-ID: <20000104.201137.07107980.taka@kawate.net>

かわてと申します。初めまして。

In the message "Re: none",
    On 04 Jan 2000 19:19:06 +0900,
    Keiichi Suzuki <keiichi ＠ nanap.org> wrote:

> すみません、直接送ろうと思っていたのに、 ML の方に投げてしまいました。 ^^;;;

"-ctl"をつけるのを忘れておりました。

ご迷惑をおかけして申し訳ありません。

-----
Takayoshi "TK" KAWATE
taka ＠ kawate.net



From teranisi ＠ gohome.org  Tue Jan 11 10:02:21 2000
From: teranisi ＠ gohome.org (Yuuichi Teranishi)
Date: Tue, 11 Jan 2000 10:02:21 +0900
Subject: cannot open autoconverted message by smtp ?
In-Reply-To: In your message of "Fri, 7 Jan 2000 15:21:02 +0900"
	<uogaytnbu.wl@mik.hml.cl.nec.co.jp>
References: <uogaytnbu.wl@mik.hml.cl.nec.co.jp>
Message-ID: <fzaemdfmjm.wl@gohome.org>


Cc: emacs-mime-ja にしました。

At Fri, 7 Jan 2000 15:21:02 +0900,
Mikiya Tani <m-tani ＠ hml.cl.nec.co.jp> wrote:
> 
> User-Agentな環境で使用しております. MLに流れてきたメールで全く開けない
> メールが来たので御報告しておきます.
> 
> Wrong type argument: stringp, nil
> 
> が出ておわりです. メールを添付するのは、どうかとは思うので
> BackTraceだけ付けておきます. 
> 
> 基本的には、
> 
> 1) Outlookから発信したSJISのバイナリメールを
> X-Mailer: Microsoft Outlook Express 4.72.3155.0
> 
> 2) そのサイト(mailbank.ne.jp)のsmtpサーバがbase64にEncodeし、
> Content-Type: text/plain;
> 	charset="euc-jp"
> Content-Transfer-Encoding: base64
> X-MIME-Autoconverted: from 8bit to base64 by smtpb.mailbank.ne.jp id JAA16167
> 
> 3) 受信したMLのサーバ(java3djp-ML)でテキストの広告をそこに付けた. 
> 
> という感じに見えます. そのため、見えないというのはあたり前のような気も
> するのですが、全く見えないとなるとやはり気になるので...。
> 

これはたぶん、base64 の文字列が改変されたために
デコード結果が nil になって起きていると思われます。
…が、Wrong type argument: stringp, nil というのはあんまりな気がするので、
mmbuffer.el の mime-entity-content で
以下のようにエラーとするのがいいかなという気がします。

(luna-define-method mime-entity-content ((entity mime-buffer-entity))
  (save-excursion
    (set-buffer (mime-buffer-entity-buffer-internal entity))
    (or (mime-decode-string
	 (buffer-substring (mime-buffer-entity-body-start-internal entity)
			   (mime-buffer-entity-body-end-internal entity))
	 (mime-entity-encoding entity))
	(error "Invalid encoded content"))))

Wanderlust では 'M' を押せば MIME 解析なしで表示します。

--
Yuuichi Teranishi (寺西裕一) <teranisi ＠ gohome.org>
PGP 5.0i Public Key: http://www.gohome.org/pgp5/teranisi.key
"So we sailed out of the sun till we found the see of green..."



From Makoto.Nakagawa ＠ jp.compaq.com  Tue Jan 11 11:27:55 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 11 Jan 2000 11:27:55 +0900
Subject: pgg-pgp5
Message-ID: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

いくつか気が付いた点がありましたのでパッチを作成してみました。
emiko-1_13-200001060443 へのパッチです。

・pgp と pgp5 で verify-region がタイミング(検証対象が大きくなると？)に
  よっては SIGPIPE のエラーとなります。pgg-*-process-region を使うのばま
  ずそうなので、call-process を使用するように変更してみました。
  
  semi-pgpgpg では問題がないのは call-process-region と 
  pgg-*-process-region の仕様の差のようです。

・pgp と pgp5 で lookup-key-string での call-process への引数の数が間違っ
  ているようなので修正しました。

・gpg で lookup-key-string を call-process でおこなうように変更してみま
  した。入力を取らないのに pgg-gpg-process-region を利用するのは上の例も
  あって気持ちが悪いように思いました。pgp、pgp5 の両方での実装に合わせた
  だけです。

とりあえず動作しているようです。

-------------- next part --------------
--- pgg-gpg.el.orig	Fri Nov 26 15:29:09 1999
+++ pgg-gpg.el	Tue Jan 11 02:56:17 2000
@@ -136,8 +136,10 @@
   (let ((args (list "--with-colons" "--no-greeting" "--batch" 
 		    (if type "--list-secret-keys" "--list-keys")
 		    string)))
-    (pgg-gpg-process-region (point)(point) nil pgg-gpg-program args)
-    (with-current-buffer pgg-output-buffer
+    (with-current-buffer (get-buffer-create pgg-output-buffer)
+      (buffer-disable-undo)
+      (erase-buffer)
+      (apply #'call-process pgg-gpg-program nil t nil args)
       (goto-char (point-min))
       (when (re-search-forward "^\\(sec\\|pub\\):"  nil t)
 	(substring 
--- pgg-pgp5.el.orig	Fri Nov 26 15:29:10 1999
+++ pgg-pgp5.el	Tue Jan 11 03:24:11 2000
@@ -140,7 +140,7 @@
     (with-current-buffer (get-buffer-create pgg-output-buffer)
       (buffer-disable-undo)
       (erase-buffer)
-      (apply #'call-process pgg-pgp5-pgpk-program  nil t args)
+      (apply #'call-process pgg-pgp5-pgpk-program nil t nil args)
       (goto-char (point-min))
       (when (re-search-forward "^sec" nil t)
 	(substring 
@@ -216,8 +216,12 @@
 				   start end &optional signature)
   (let* ((basename (expand-file-name "pgg" temporary-file-directory))
 	 (orig-file (make-temp-name basename))
-	 (args '("+verbose=1" "+batchmode=1" "+language=us"))
-	 (orig-mode (default-file-modes)))
+	 (args
+	  (append
+	   '("+verbose=1" "+batchmode=1" "+language=us")
+	   pgg-pgp5-extra-args))
+	 (orig-mode (default-file-modes))
+	 exit-status)
     (unwind-protect
 	(progn
 	  (set-default-file-modes 448)
@@ -228,8 +232,16 @@
       (copy-file signature (setq signature (concat orig-file ".asc")))
       (setq args (append args (list signature)))
       )
-    (pgg-pgp5-process-region (point-min)(point-max) nil
-			     pgg-pgp5-pgpv-program args)
+    (with-current-buffer (get-buffer-create pgg-output-buffer)
+      (buffer-disable-undo)
+      (erase-buffer)
+      (setq exit-status
+	    (apply #'call-process pgg-pgp5-pgpv-program nil t nil args))
+
+      (pgg-convert-lbt-region (point-min)(point-max) 'LF)
+
+      (if (= 127 exit-status)
+	  (error "%s could not be found" program)))
     (delete-file orig-file)
     (if signature (delete-file signature))
     (pgg-process-when-success nil)
--- pgg-pgp.el.orig	Fri Nov 26 15:29:10 1999
+++ pgg-pgp.el	Tue Jan 11 03:24:07 2000
@@ -125,7 +125,7 @@
     (with-current-buffer (get-buffer-create pgg-output-buffer)
       (buffer-disable-undo)
       (erase-buffer)
-      (apply #'call-process pgg-pgp-program nil t args)
+      (apply #'call-process pgg-pgp-program nil t nil args)
       (goto-char (point-min))
       (cond
        ((re-search-forward "^pub\\s +[0-9]+/" nil t);PGP 2.*
@@ -204,7 +204,10 @@
 				   start end &optional signature)
   (let* ((basename (expand-file-name "pgg" temporary-file-directory))
 	 (orig-file (make-temp-name basename))
-	 (args '("+verbose=1" "+batchmode" "+language=us"))
+	 (args
+	  (append
+	   '("+verbose=1" "+batchmode" "+language=us")
+	   pgg-pgp-extra-args))
 	 (orig-mode (default-file-modes)))
     (unwind-protect
 	(progn
@@ -216,8 +219,16 @@
       (copy-file signature (setq signature (concat orig-file ".asc")))
       (setq args (append args (list signature orig-file)))
       )
-    (pgg-pgp-process-region (point-min)(point-max) nil
-			    pgg-pgp-program args)
+    (with-current-buffer (get-buffer-create pgg-output-buffer)
+      (buffer-disable-undo)
+      (erase-buffer)
+      (setq exit-status
+	    (apply #'call-process pgg-pgp-program nil t nil args))
+
+      (pgg-convert-lbt-region (point-min)(point-max) 'LF)
+
+      (if (= 127 exit-status)
+	  (error "%s could not be found" program)))
     (delete-file orig-file)
     (if signature (delete-file signature))
     (pgg-process-when-success

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     366 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000111/3b3762f0/attachment.pgp>

From Makoto.Nakagawa ＠ jp.compaq.com  Tue Jan 11 11:51:05 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 11 Jan 2000 11:51:05 +0900
Subject: pgg-pgp5
In-Reply-To: =?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of
 "11 Jan 2000 11:27:55
 +0900"<14458.38187.449000.697647@manakagawa-nt.osa.dec.com>
References: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com>
Message-ID: <14458.39577.788000.366239@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

pgg-pgp.el へのパッチに漏れがありました。パッチを手で修正したのでうまく
あたらないかもしれませんが、意図は汲んでいただけると思います。

ごめんなさい。

-------------- next part --------------
--- pgg-pgp.el.orig	Fri Nov 26 15:29:10 1999
+++ pgg-pgp.el	Tue Jan 11 03:24:07 2000
@@ -125,7 +125,7 @@
     (with-current-buffer (get-buffer-create pgg-output-buffer)
       (buffer-disable-undo)
       (erase-buffer)
-      (apply #'call-process pgg-pgp-program nil t args)
+      (apply #'call-process pgg-pgp-program nil t nil args)
       (goto-char (point-min))
       (cond
        ((re-search-forward "^pub\\s +[0-9]+/" nil t);PGP 2.*
@@ -204,7 +204,11 @@
 				   start end &optional signature)
   (let* ((basename (expand-file-name "pgg" temporary-file-directory))
 	 (orig-file (make-temp-name basename))
-	 (args '("+verbose=1" "+batchmode" "+language=us"))
- 	 (orig-mode (default-file-modes)))
+	 (args
+	  (append
+	   '("+verbose=1" "+batchmode" "+language=us")
+	   pgg-pgp-extra-args))
+ 	 (orig-mode (default-file-modes))
+	 exit-status)
     (unwind-protect
 	(progn
@@ -216,8 +220,16 @@
       (copy-file signature (setq signature (concat orig-file ".asc")))
       (setq args (append args (list signature orig-file)))
       )
-    (pgg-pgp-process-region (point-min)(point-max) nil
-			    pgg-pgp-program args)
+    (with-current-buffer (get-buffer-create pgg-output-buffer)
+      (buffer-disable-undo)
+      (erase-buffer)
+      (setq exit-status
+	    (apply #'call-process pgg-pgp-program nil t nil args))
+
+      (pgg-convert-lbt-region (point-min)(point-max) 'LF)
+
+      (if (= 127 exit-status)
+	  (error "%s could not be found" program)))
     (delete-file orig-file)
     (if signature (delete-file signature))
     (pgg-process-when-success

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     366 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000111/b866f73c/attachment.pgp>

From saka ＠ yugen.org  Tue Jan 11 21:24:14 2000
From: saka ＠ yugen.org (SAKA Toshihide (=?ISO-2022-JP?B?GyRCOmQbKEIgGyRCSVI9KBsoQg==?=))
Date: Tue, 11 Jan 2000 21:24:14 +0900
Subject: patch for: semi-1.13.7 & flim-1.13.2
Message-ID: <20000111212417R.saka@yugen.org>

坂といいます。はじめまして。

SEMI (FLIM) 付属の Makefile に mime-ui-{en,ja}.info
(mime-{en,ja}.info) を作るエントリが無かったので、Wanderlust の WL-MK 
および Makefile を参考に SEMI (FLIM) 用のエントリを作ってみました。

P.S.
.texi と .info の関連付けは alist を使うべきなのでしょうが、Emacs Lisp 
に疎いので、そこまでできませんでした(汗)。

WL-MK で wl-cs-local としてあった個所は 'iso-2022-jp などとしてしまい
ました(汗)。もしお気に召されないようでしたら、適当に書き換えてくださっ
てかまいません。

-------------- next part --------------
diff -uaNr semi-1.13.7.orig/Makefile semi-1.13.7/Makefile
--- semi-1.13.7.orig/Makefile	Sat Oct 16 17:18:06 1999
+++ semi-1.13.7/Makefile	Tue Jan 11 20:56:09 2000
@@ -67,3 +67,6 @@
 release:
 	-$(RM) $(ARC_DIR)/$(PACKAGE)-$(VERSION).tar.gz
 	mv /tmp/$(PACKAGE)-$(VERSION).tar.gz $(ARC_DIR)
+
+info:
+	$(EMACS) $(FLAGS) -f semi-texinfo-format $(INFODIR)
diff -uaNr semi-1.13.7.orig/SEMI-MK semi-1.13.7/SEMI-MK
--- semi-1.13.7.orig/SEMI-MK	Mon Jul 26 16:17:32 1999
+++ semi-1.13.7/SEMI-MK	Tue Jan 11 20:57:21 2000
@@ -4,6 +4,10 @@
 
 ;;; Code:
 
+(defvar DOCDIR "./")
+(defconst SEMI-INFO-LIST '("mime-ui-en.info" "mime-ui-ja.info"))
+(defconst SEMI-TEXI-LIST '("mime-ui-en.texi" "mime-ui-ja.texi"))
+
 (defun config-semi ()
   (let (prefix exec-prefix lisp-dir version-specific-lisp-dir)
     (and (setq prefix (car command-line-args-left))
@@ -91,5 +95,43 @@
 					   (expand-file-name "lisp"
 							     PACKAGEDIR)))
   )
+
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;; Texinfo stuff
+
+(defun semi-texinfo-format ()
+;  (unless INFODIR
+;    (setq INFODIR (wl-detect-info-directory)))
+;  (require 'wl-vars) ;; for 'wl-cs-local
+  (let (SEMI-INFO SEMI-TEXI)
+    (while (and SEMI-INFO-LIST SEMI-TEXI-LIST)
+      (setq SEMI-INFO (car SEMI-INFO-LIST))
+      (setq SEMI-TEXI (car SEMI-TEXI-LIST))
+      (setq SEMI-INFO-LIST (cdr SEMI-INFO-LIST))
+      (setq SEMI-TEXI-LIST (cdr SEMI-TEXI-LIST))
+      (or (file-newer-than-file-p (expand-file-name SEMI-INFO DOCDIR)
+				  (expand-file-name SEMI-TEXI DOCDIR))
+	  (let (obuf beg)
+	    (find-file (expand-file-name SEMI-TEXI DOCDIR))
+	    (setq obuf (current-buffer))
+	    ;; texinfmt.el 2.37 or earlier can't format @direntry
+	    (require 'texinfmt)
+	    (unless (fboundp 'texinfo-format-direntry)
+	      (goto-char (point-min))
+	      (when (re-search-forward "^@direntry" nil t)
+		(replace-match "@ifinfo\nSTART-INFO-DIR-ENTRY"))
+	      (when (re-search-forward "^@end direntry" nil t)
+		(replace-match "END-INFO-DIR-ENTRY\n ＠ end ifinfo"))
+	      (set-buffer-modified-p nil))
+	    ;; We can't know file names if splitted.
+	    (texinfo-format-buffer t)
+	    ;; Emacs20.2's default is 'raw-text-unix.
+	    (and (fboundp 'set-buffer-file-coding-system)
+		 ;;	     (set-buffer-file-coding-system wl-cs-local))
+		 (set-buffer-file-coding-system 'iso-2022-jp))
+	    (save-buffer)
+	    (kill-buffer (current-buffer)) ;; info
+	    (kill-buffer obuf)) ;; texi
+	  ))))
 
 ;;; SEMI-MK ends here
-------------- next part --------------
diff -uaNr flim-1.13.2.orig/FLIM-MK flim-1.13.2/FLIM-MK
--- flim-1.13.2.orig/FLIM-MK	Sun Oct 18 17:03:26 1998
+++ flim-1.13.2/FLIM-MK	Tue Jan 11 20:44:45 2000
@@ -4,6 +4,12 @@
 
 ;;; Code:
 
+;;; Code
+
+(defvar DOCDIR "./")
+(defconst FLIM-INFO-LIST '("mime-en.info" "mime-ja.info"))
+(defconst FLIM-TEXI-LIST '("mime-en.texi" "mime-ja.texi"))
+
 (defun config-flim ()
   (let (prefix lisp-dir version-specific-lisp-dir)
     (and (setq prefix (car command-line-args-left))
@@ -75,5 +81,43 @@
 					   (expand-file-name "lisp"
 							     PACKAGEDIR)))
   )
+
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;; Texinfo stuff
+
+(defun flim-texinfo-format ()
+;  (unless INFODIR
+;    (setq INFODIR (wl-detect-info-directory)))
+;  (require 'wl-vars) ;; for 'wl-cs-local
+  (let (FLIM-INFO FLIM-TEXI)
+    (while (and FLIM-INFO-LIST FLIM-TEXI-LIST)
+      (setq FLIM-INFO (car FLIM-INFO-LIST))
+      (setq FLIM-TEXI (car FLIM-TEXI-LIST))
+      (setq FLIM-INFO-LIST (cdr FLIM-INFO-LIST))
+      (setq FLIM-TEXI-LIST (cdr FLIM-TEXI-LIST))
+      (or (file-newer-than-file-p (expand-file-name FLIM-INFO DOCDIR)
+				  (expand-file-name FLIM-TEXI DOCDIR))
+	  (let (obuf beg)
+	    (find-file (expand-file-name FLIM-TEXI DOCDIR))
+	    (setq obuf (current-buffer))
+	    ;; texinfmt.el 2.37 or earlier can't format @direntry
+	    (require 'texinfmt)
+	    (unless (fboundp 'texinfo-format-direntry)
+	      (goto-char (point-min))
+	      (when (re-search-forward "^@direntry" nil t)
+		(replace-match "@ifinfo\nSTART-INFO-DIR-ENTRY"))
+	      (when (re-search-forward "^@end direntry" nil t)
+		(replace-match "END-INFO-DIR-ENTRY\n ＠ end ifinfo"))
+	      (set-buffer-modified-p nil))
+	    ;; We can't know file names if splitted.
+	    (texinfo-format-buffer t)
+	    ;; Emacs20.2's default is 'raw-text-unix.
+	    (and (fboundp 'set-buffer-file-coding-system)
+		 ;;	     (set-buffer-file-coding-system wl-cs-local))
+		 (set-buffer-file-coding-system 'iso-2022-jp))
+	    (save-buffer)
+	    (kill-buffer (current-buffer)) ;; info
+	    (kill-buffer obuf)) ;; texi
+	  ))))
 
 ;;; FLIM-MK ends here
diff -uaNr flim-1.13.2.orig/Makefile flim-1.13.2/Makefile
--- flim-1.13.2.orig/Makefile	Tue Aug 17 11:09:50 1999
+++ flim-1.13.2/Makefile	Tue Jan 11 20:41:57 2000
@@ -66,3 +66,6 @@
 	mv /tmp/$(PACKAGE)-$(VERSION).tar.gz $(ARC_DIR)
 	cd $(SEMI_ARC_DIR) ; \
 		ln -s ../../flim/flim-$(API)/$(PACKAGE)-$(VERSION).tar.gz .
+
+info:
+	$(EMACS) $(FLAGS) -f flim-texinfo-format $(INFODIR)
-------------- next part --------------
-- 
SAKA Toshihide mailto:saka ＠ yugen.org
Department of Architecture, the University of Tokyo


From ueno ＠ ueda.info.waseda.ac.jp  Tue Jan 11 23:32:42 2000
From: ueno ＠ ueda.info.waseda.ac.jp (Daiki Ueno)
Date: Tue, 11 Jan 2000 23:32:42 +0900
Subject: pgg-pgp5
In-Reply-To: In your message of "11 Jan 2000 11:27:55 +0900"
	<14458.38187.449000.697647@manakagawa-nt.osa.dec.com>
References: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com>
Message-ID: <87n1qcwuet.wl@ueda.info.waseda.ac.jp>

At 11 Jan 2000 11:27:55 +0900,
中川 誠 <Makoto.Nakagawa ＠ jp.compaq.com> wrote:
> 
> いくつか気が付いた点がありましたのでパッチを作成してみました。
> emiko-1_13-200001060443 へのパッチです。

ありがとうございます。
早速ですが、ChangeLog をいただけますでしょうか？^^;;

;; PGP5.* に関しては、実は捨てようかと ^^;;; 考えていたこともあり、
;; あまりテストしていません。すみません。
 
> ・pgp と pgp5 で verify-region がタイミング(検証対象が大きくなると？)に
>   よっては SIGPIPE のエラーとなります。pgg-*-process-region を使うのばま
>   ずそうなので、call-process を使用するように変更してみました。
>   
verify-region に関しては、できれば pgg-*-process-region を修正して
いただけないでしょうか。

pgg-*-process-region の仕様としては、call-process-region で、
各 PGP コマンドを呼び出したあと、pgg-{errors,output,status}-buffer の 
3 つのバッファに出力を振り分けるという役割があるので、
単純に call-process で置き換えることはできないような気がします。

>   semi-pgpgpg では問題がないのは call-process-region と 
>   pgg-*-process-region の仕様の差のようです。

;; 差というのは process-connection-type でしょうかねぇ？

> ・pgp と pgp5 で lookup-key-string での call-process への引数の数が間違っ
>   ているようなので修正しました。

> ・gpg で lookup-key-string を call-process でおこなうように変更してみま
>   した。入力を取らないのに pgg-gpg-process-region を利用するのは上の例も
>   あって気持ちが悪いように思いました。pgp、pgp5 の両方での実装に合わせた
>   だけです。

lookup-key-string は単なる補助関数なので、そのまま取り込みたいと思います。
--
Daiki Ueno (ueno ＠ ueda.info.waseda.ac.jp)



From ueno ＠ ueda.info.waseda.ac.jp  Wed Jan 12 02:43:09 2000
From: ueno ＠ ueda.info.waseda.ac.jp (Daiki Ueno)
Date: Wed, 12 Jan 2000 02:43:09 +0900
Subject: mailcap search path
Message-ID: <87aemcpkr6.wl@ueda.info.waseda.ac.jp>

RFC 1524 の "Location of the Mailcap File(s)" によると、
UNIX 上では、mailcap の検索パスを指定できることになっていますが、
mime-view.el では、mailcap-file (~/.mailcap) だけを参照するようです。
そこで、ding の mailcap.el から該当部分を切り取って、以下のようなもの
を書いてみました。

;; 汚い部分なので、どこに入れるべきかは判りかねます。^_^;;

(defcustom mailcap-files 
  (if (memq system-type '(ms-dos ms-windows windows-nt))
      '("~/mail.cap" "~/etc/mail.cap" "~/.mailcap")
    '("~/.mailcap" "/etc/mailcap" "/usr/etc/mailcap"
      "/usr/local/etc/mailcap"))
  "*Search path of mailcap files."
  :group 'mime
  :type '(repeat file))

(defun mailcap-parse-files (&optional path order)
  "Parse out all mailcaps specified in a unix-style path string PATH.
If optional argument ORDER is a function, result is sorted by it.
If optional argument ORDER is not specified, result is sorted original
order.  Otherwise result is not sorted."
  (let ((mailcap-files 
	 (if (or path (setq path (getenv "MAILCAPS")))
	     (split-string path
			   (if (memq system-type
				     '(ms-dos ms-windows windows-nt))
			       ";"
			     ":"))
	   mailcap-files))
	entries)
    (dolist (file mailcap-files)
      (if (file-readable-p file)
	  (setq entries (nconc entries (mailcap-parse-file file t)))))
    (cond ((functionp order) (sort entries order))
	  ((null order) (nreverse entries))
	  (t entries))))

--
Daiki Ueno (ueno ＠ ueda.info.waseda.ac.jp)



From Makoto.Nakagawa ＠ jp.compaq.com  Wed Jan 12 11:04:26 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 12 Jan 2000 11:04:26 +0900
Subject: pgg-pgp5
In-Reply-To: Daiki Ueno's message of "Tue, 11 Jan 2000 23:32:42 +0900"	<87n1qcwuet.wl@ueda.info.waseda.ac.jp>
References: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com>
	<87n1qcwuet.wl@ueda.info.waseda.ac.jp>
Message-ID: <14459.57642.156000.774548@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: pgg-pgp5"
    on 00/01/11, Daiki Ueno <ueno ＠ ueda.info.waseda.ac.jp> wrote:

  > 早速ですが、ChangeLog をいただけますでしょうか？^^;;

verify-region を call-process を使用しないように修正するにしても、とりあ
えず前回のパッチに対する ChangeLog を書く、でよいのでしょうか。

  > verify-region に関しては、できれば pgg-*-process-region を修正して
  > いただけないでしょうか。

最初はそう思ったのですが、どういう仕様にするのがよいのか判断がつきかねま
した。

pgg-*-process-region に起動したプロセスに対して process-send-region しな
いためのオプショナルな引き数を追加、という変更しか思いつかないのですが、
この方針でよいでしょうか。

process-region という名前と相性が悪いのでいやだなぁ、と思ったのです。

  > pgg-*-process-region の仕様としては、call-process-region で、
  > 各 PGP コマンドを呼び出したあと、pgg-{errors,output,status}-buffer の 
  > 3 つのバッファに出力を振り分けるという役割があるので、
  > 単純に call-process で置き換えることはできないような気がします。

で、自分の使用している範囲で verify の動作を外から眺めてみた結果、
call-process でも問題はなかろうと判断しました。

  >> semi-pgpgpg では問題がないのは call-process-region と 
  >> pgg-*-process-region の仕様の差のようです。

  > ;; 差というのは process-connection-type でしょうかねぇ？

process-connection-type を describe-variable してみましたが、私にはちょっ
と意味が分りかねます。


# 関係のない話題でなんなのですが、pgp-users ML へ出したメールが返ってき
# てしまったのですが、私の側の問題でしょうか。

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000112/e96f6b8a/attachment.pgp>

From ueno ＠ ueda.info.waseda.ac.jp  Wed Jan 12 12:40:09 2000
From: ueno ＠ ueda.info.waseda.ac.jp (Daiki Ueno)
Date: 12 Jan 2000 12:40:09 +0900
Subject: pgg-pgp5
In-Reply-To: <14459.57642.156000.774548@manakagawa-nt.osa.dec.com>
 (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of "12 Jan 2000
 11:04:26 +0900")
References: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com> <87n1qcwuet.wl@ueda.info.waseda.ac.jp> <14459.57642.156000.774548@manakagawa-nt.osa.dec.com>
Message-ID: <87d7r8gdpi.fsf@pc29.ueda.info.waseda.ac.jp>

Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) writes:

>   > 早速ですが、ChangeLog をいただけますでしょうか？^^;;
> 
> verify-region を call-process を使用しないように修正するにしても、とりあ
> えず前回のパッチに対する ChangeLog を書く、でよいのでしょうか。

はい。お願いします。

> pgg-*-process-region に起動したプロセスに対して process-send-region しな
> いためのオプショナルな引き数を追加、という変更しか思いつかないのですが、
> この方針でよいでしょうか。
> 
> process-region という名前と相性が悪いのでいやだなぁ、と思ったのです。

確かに、PGP, PGP5.* の場合には一度ファイルに書き出してから
process-send-region しているので、二度手間だとは思います。
この際、GnuPG とは全く別の実装にしたほうが良いのではと思います。
 
>   > pgg-*-process-region の仕様としては、call-process-region で、
>   > 各 PGP コマンドを呼び出したあと、pgg-{errors,output,status}-buffer の 
>   > 3 つのバッファに出力を振り分けるという役割があるので、
>   > 単純に call-process で置き換えることはできないような気がします。
> 
> で、自分の使用している範囲で verify の動作を外から眺めてみた結果、
> call-process でも問題はなかろうと判断しました。

具体的には、署名検証が失敗した際に、pgg-*-process-region を利用した
verify-region では nil を返し、call-process を利用した先の例では、
無条件に t を返してしまうと思うのですが、どうでしょう？

;; call-process-shell-command を使っているのは、単に標準エラー出力を
;; 標準出力から分離する目的だったと思います。

>   >> semi-pgpgpg では問題がないのは call-process-region と 
>   >> pgg-*-process-region の仕様の差のようです。
> 
>   > ;; 差というのは process-connection-type でしょうかねぇ？
> 
> process-connection-type を describe-variable してみましたが、私にはちょっ
> と意味が分りかねます。

pgg-*-process-region では、process-connection-type を nil に束縛し、
PGP コマンドとのやりとりに pipe を利用しています。
既定値は t (pty) ですが、純粋に subprocess として利用する場合には、
pipe のほうが効率が良いのではなかったかと。

;; と、少し前に、Wanderlust ML のほうで話題になっていました。
;; > http://lists.airs.net/wl/archive/199911/msg00383.html
--
Daiki Ueno (ueno ＠ ueda.info.waseda.ac.jp)



From Makoto.Nakagawa ＠ jp.compaq.com  Wed Jan 12 17:21:28 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 12 Jan 2000 17:21:28 +0900
Subject: pgg-pgp5
In-Reply-To: Daiki Ueno's message of "12 Jan 2000 12:40:09 +0900"	<87d7r8gdpi.fsf@pc29.ueda.info.waseda.ac.jp>
References: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com>
	<87n1qcwuet.wl@ueda.info.waseda.ac.jp>
	<14459.57642.156000.774548@manakagawa-nt.osa.dec.com>
	<87d7r8gdpi.fsf@pc29.ueda.info.waseda.ac.jp>
Message-ID: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: pgg-pgp5"
    on 00/01/12, Daiki Ueno <ueno ＠ ueda.info.waseda.ac.jp> wrote:

  >> verify-region を call-process を使用しないように修正するにしても、とりあ
  >> えず前回のパッチに対する ChangeLog を書く、でよいのでしょうか。

  > はい。お願いします。

ではとりあえず。

2000-01-11  中川 誠  <Makoto.Nakagawa ＠ jp.compaq.com>

	* pgg-pgp5.el (lookup-key-string): Wrong number of arguments
	against call-process.

	* pgg-pgp.el (lookup-key-string): Ditto.

	* pgg-pgp5.el (verify-region): Do not use pgg-*-process-region,
	but call-process.

	* pgg-pgp.el (verify-region): Ditto.

	* pgg-gpg.el (lookup-key-string): Ditto.

# 手抜きしすぎでしょうか。

  > 具体的には、署名検証が失敗した際に、pgg-*-process-region を利用した
  > verify-region では nil を返し、call-process を利用した先の例では、
  > 無条件に t を返してしまうと思うのですが、どうでしょう？

というか、署名検証の正否にかかわらず、pgg-*-process-region を利用すると
nil が返り、call-process を利用すると t が返りますね。

  > この際、GnuPG とは全く別の実装にしたほうが良いのではと思います。
 
確かに GnuPG の verify のようにバッファを解析して正否を判断するのがよさ
そうですね。ちょいと挑戦してみます。

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000112/cf8cd1a1/attachment.pgp>

From ueno ＠ ueda.info.waseda.ac.jp  Wed Jan 12 18:22:21 2000
From: ueno ＠ ueda.info.waseda.ac.jp (Daiki Ueno)
Date: 12 Jan 2000 18:22:21 +0900
Subject: pgg-pgp5
In-Reply-To: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
 (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of "12 Jan 2000
 17:21:28 +0900")
References: <14458.38187.449000.697647@manakagawa-nt.osa.dec.com> <87n1qcwuet.wl@ueda.info.waseda.ac.jp> <14459.57642.156000.774548@manakagawa-nt.osa.dec.com> <87d7r8gdpi.fsf@pc29.ueda.info.waseda.ac.jp> <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
Message-ID: <87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp>

Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) writes:

>   > 具体的には、署名検証が失敗した際に、pgg-*-process-region を利用した
>   > verify-region では nil を返し、call-process を利用した先の例では、
>   > 無条件に t を返してしまうと思うのですが、どうでしょう？
> 
> というか、署名検証の正否にかかわらず、pgg-*-process-region を利用すると
> nil が返り、call-process を利用すると t が返りますね。
> 
>   > この際、GnuPG とは全く別の実装にしたほうが良いのではと思います。
>  
> 確かに GnuPG の verify のようにバッファを解析して正否を判断するのがよさ
> そうですね。ちょいと挑戦してみます。

すみません。^_^;; よくよく考えると、pgg-*-process-region が
process-exit-status を返すようにし、これで正否を判断するほうが確実なよう
な気がしてきました。今日帰ったら、少し調べてみます。

;; どうして出力で判断しようとしたんだろう…
--
Daiki Ueno (ueno ＠ ueda.info.waseda.ac.jp)



From Makoto.Nakagawa ＠ jp.compaq.com  Wed Jan 12 18:37:18 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 12 Jan 2000 18:37:18 +0900
Subject: pgg-pgp5
In-Reply-To: Daiki Ueno's message of "12 Jan 2000 18:22:21 +0900"	<87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp>
References: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
	<87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp>
Message-ID: <14460.19278.428000.366239@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: pgg-pgp5"
    on 00/01/12, Daiki Ueno <ueno ＠ ueda.info.waseda.ac.jp> wrote:

  > すみません。^_^;; よくよく考えると、pgg-*-process-region が
  > process-exit-status を返すようにし、これで正否を判断するほうが確実なよう
  > な気がしてきました。今日帰ったら、少し調べてみます。

process-exit-status では正否を判断できないのではないでしょうか。pgp2、
pgp5 では署名検証の正否にかかわらず process-exit-status は 0 になりませ
んか。

gpg on cygwin だと verify 時に status-file が生成されないみたい。私のと
こだけでしょうか。誰か他に win32 な環境の方はおられますか。

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000112/b0e3e0ff/attachment.pgp>

From ueno ＠ ueda.info.waseda.ac.jp  Wed Jan 12 19:19:01 2000
From: ueno ＠ ueda.info.waseda.ac.jp (Daiki Ueno)
Date: 12 Jan 2000 19:19:01 +0900
Subject: pgg-pgp5
In-Reply-To: <14460.19278.428000.366239@manakagawa-nt.osa.dec.com>
 (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of "12 Jan 2000
 18:37:18 +0900")
References: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com> <87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp> <14460.19278.428000.366239@manakagawa-nt.osa.dec.com>
Message-ID: <8766wzr3sa.fsf@pc29.ueda.info.waseda.ac.jp>

Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) writes:

>   > すみません。^_^;; よくよく考えると、pgg-*-process-region が
>   > process-exit-status を返すようにし、これで正否を判断するほうが確実なよう
>   > な気がしてきました。今日帰ったら、少し調べてみます。
> 
> process-exit-status では正否を判断できないのではないでしょうか。pgp2、
> pgp5 では署名検証の正否にかかわらず process-exit-status は 0 になりませ
> んか。

手元に PGP6.* の説明書しかないので、あまり当てになりませんが、
+batchmode=on の状態では、0 以外を返すようです。
("Understanding PGP exit status codes")

PGP5.* の man には記述が無いようですが、ソースを見る限り、
同様ではないですかねぇ？
--
Daiki Ueno (ueno ＠ ueda.info.waseda.ac.jp)



From tomo ＠ etl.go.jp  Wed Jan 12 19:27:55 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 12 Jan 2000 19:27:55 +0900
Subject: cvs.m17n.org
In-Reply-To: tomo@etl.go.jp's message of "27 Dec 1999 19:49:19 +0900"
References: <htxg0woslow.fsf_-_@mulelab3.etl.go.jp>
Message-ID: <htxg0w3shxw.fsf_-_@mulelab3.etl.go.jp>

>>>>> In [apel-ja : No.00226] 
>>>>>	"守岡" = tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

守岡> ;; snapshot 自動生成は年明け以後で良いでしょうか？また、cvsweb 
守岡> ;; とか CVS repository の anonymous-ftp 経由での公開とか要ります？

とりあえず cvsweb を動かしてみました。場所は

http://cvs.m17n.org/

です。

;; もっともあんまり便利じゃない気もしますが。(^_^;;;

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━



From Makoto.Nakagawa ＠ jp.compaq.com  Wed Jan 12 19:43:59 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 12 Jan 2000 19:43:59 +0900
Subject: pgg-pgp5
In-Reply-To: Daiki Ueno's message of "12 Jan 2000 19:19:01 +0900"	<8766wzr3sa.fsf@pc29.ueda.info.waseda.ac.jp>
References: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
	<87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp>
	<14460.19278.428000.366239@manakagawa-nt.osa.dec.com>
	<8766wzr3sa.fsf@pc29.ueda.info.waseda.ac.jp>
Message-ID: <14460.23279.211000.590211@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: pgg-pgp5"
    on 00/01/12, Daiki Ueno <ueno ＠ ueda.info.waseda.ac.jp> wrote:

  > 手元に PGP6.* の説明書しかないので、あまり当てになりませんが、
  > +batchmode=on の状態では、0 以外を返すようです。
  > ("Understanding PGP exit status codes")

  > PGP5.* の man には記述が無いようですが、ソースを見る限り、
  > 同様ではないですかねぇ？

およ。私の pgp5 on cygwin では +batchmode=1 でも検証の正否にかかわらず
call-process の返す値は 0 になりますね。

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000112/f0d1c736/attachment.pgp>

From ume ＠ bisd.hitachi.co.jp  Wed Jan 12 19:50:37 2000
From: ume ＠ bisd.hitachi.co.jp (Hajimu UMEMOTO (=?iso-2022-jp?B?GyRCR19LXBsoQiAbJEJIJRsoQg==?=))
Date: Wed, 12 Jan 2000 19:50:37 +0900
Subject: cvs.m17n.org
In-Reply-To: <htxg0w3shxw.fsf_-_@mulelab3.etl.go.jp>
References: <htxg0woslow.fsf_-_@mulelab3.etl.go.jp>
	<htxg0w3shxw.fsf_-_@mulelab3.etl.go.jp>
Message-ID: <200001121050.e0CAobu15414@plum.ssr.bisd.hitachi.co.jp>

  梅本＠日立です。

>>>>> On 12 Jan 2000 19:27:55 +0900
>>>>> tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) said:

tomo> ;; もっともあんまり便利じゃない気もしますが。(^_^;;;

  Zellers の CVSweb の方が嬉しいかも知れません。:-)

	http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi

--
梅本 肇＠（株）日立製作所 ビジネスソリューション開発本部
E-Mail: ume ＠ bisd.hitachi.co.jp ume ＠ mahoroba.org ume ＠ jp.FreeBSD.org
URL: http://www.imasy.org/~ume/



From Makoto.Nakagawa ＠ jp.compaq.com  Thu Jan 13 10:51:07 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 13 Jan 2000 10:51:07 +0900
Subject: pgg-pgp5
In-Reply-To: Daiki Ueno's message of "12 Jan 2000 19:19:01 +0900"	<8766wzr3sa.fsf@pc29.ueda.info.waseda.ac.jp>
References: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
	<87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp>
	<14460.19278.428000.366239@manakagawa-nt.osa.dec.com>
	<8766wzr3sa.fsf@pc29.ueda.info.waseda.ac.jp>
Message-ID: <14461.12171.471000.401884@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: pgg-pgp5"
    on 00/01/12, Daiki Ueno <ueno ＠ ueda.info.waseda.ac.jp> wrote:

  > PGP5.* の man には記述が無いようですが、ソースを見る限り、
  > 同様ではないですかねぇ？

私が見る限りでは verify 時には 無条件に return 0 しているようです。勘違
いなのかもしれません。

ただ、linux 上でも試しましたが、やはり検証の正否に拘らず 0 が返ります。

In message "Re: pgg-pgp5"
    on 00/01/12, 中川 誠 <Makoto.Nakagawa ＠ jp.compaq.com> wrote:

  > gpg on cygwin だと verify 時に status-file が生成されないみたい。私のと
  > こだけでしょうか。誰か他に win32 な環境の方はおられますか。

これは shell に bash ではなく cmdproxy を使ってるからでしょうね、きっと。--
status-fd でファイル名を直接指定できるといいんですけど。

-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000113/2dae179b/attachment.pgp>

From yamaoka ＠ jpl.org  Thu Jan 13 10:55:46 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 12 Jan 2000 20:55:46 -0500 (EST)
Subject: pgg-pgp5
References: <14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
 <87aembr6eq.fsf@pc29.ueda.info.waseda.ac.jp>
 <14460.19278.428000.366239@manakagawa-nt.osa.dec.com>
 <8766wzr3sa.fsf@pc29.ueda.info.waseda.ac.jp>
 <14461.12171.471000.401884@manakagawa-nt.osa.dec.com>
Message-ID: <yosuogaqybtp.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00315] 
>>>>>	Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) wrote:

上野さん>> PGP5.* の man には記述が無いようですが、ソースを見る限り、
上野さん>> 同様ではないですかねぇ？

中川さん> 私が見る限りでは verify 時には 無条件に return 0 しているよ
中川さん> うです。勘違いなのかもしれません。

ぼくの記憶でもそうなっていました。:-)
-- 
~{I=8T?KC@~} <yamaoka ＠ jpl.org>



From tomo ＠ etl.go.jp  Thu Jan 13 12:47:30 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 13 Jan 2000 12:47:30 +0900
Subject: cvs.m17n.org
In-Reply-To: Hajimu UMEMOTO's message of "Wed, 12 Jan 2000 19:50:37 +0900"
References: <htxg0woslow.fsf_-_@mulelab3.etl.go.jp>
 <htxg0w3shxw.fsf_-_@mulelab3.etl.go.jp>
 <200001121050.e0CAobu15414@plum.ssr.bisd.hitachi.co.jp>
Message-ID: <htx7lhezl7x.fsf@mulelab3.etl.go.jp>

>>>>> [apel-ja : No.00244] にて
>>>>> “梅本”= Hajimu UMEMOTO (梅本 肇) <ume ＠ bisd.hitachi.co.jp> さま
      曰く:

tomo> ;; もっともあんまり便利じゃない気もしますが。(^_^;;;

梅本>   Zellers の CVSweb の方が嬉しいかも知れません。:-)

梅本> 	http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi

情報ありがとうございます。

ただ何というか、FLIM family? のような、枝が主で幹に意味がない場合には
うれしくない気がします。

各枝の list がまず出るとうれしい気がするんですが。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━



From tomo ＠ etl.go.jp  Fri Jan 14 14:01:04 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 14 Jan 2000 14:01:04 +0900
Subject: Feature of variants
In-Reply-To: Tashiron's message of "14 Dec 1999 14:19:35 +0900"
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp> <86k8mnm21x.fsf@aqua.ocn.ne.jp>
 <wkemcuhnv6.wl@mature.din.or.jp> <86yab2ld5t.fsf@aqua.ocn.ne.jp>
 <htxpuwceje2.fsf@mulelab3.etl.go.jp> <86vh64y6ry.fsf@aqua.ocn.ne.jp>
 <htxiu24d2zs.fsf@mulelab3.etl.go.jp> <86bt7vkr56.fsf@aqua.ocn.ne.jp>
 <yosuwvqjawka.fsf@jpl.org> <rv33dt6gkuw.fsf@u-aizu.ac.jp>
Message-ID: <htxiu0x1c33.fsf@mulelab3.etl.go.jp>

浦島フォローで申し訳ありません。

>>>>> [emacs-mime-ja : No.00224] にて
>>>>> “たしろ”= Tashiron <s1021044 ＠ u-aizu.ac.jp> さま曰く:

たしろ> と，ここまで盛り込んだものを(需要はないかもとも思いましたが)
たしろ> HTML にしときました．
たしろ> http://www.u-aizu.ac.jp/~s1021044/semi-variant.html

ありがとうございます。

たしろ> あと，注意書(?)やご意見みたいなものなどありましたら参考に
たしろ> したいと思いますので何でも申し付けてください．m(..

mailto: は使わない方が良いと思います。


たしろ> そのまま自分のサイトに置いておくつもりはない(そろそろ卒業で 
たしろ> account がなくなってしまうから)のでどなたか引き取って頂ける
たしろ> と嬉しいです．
たしろ> CSS を使って書いていますので，引き取って頂ける場合は
たしろ> http://www.u-aizu.ac.jp/~s1021044/base.css
たしろ> http://www.u-aizu.ac.jp/~s1021044/svariant.css
たしろ> も一緒に引き取ってくださいませ．m(..

よろしければ FLIM と SEMI の page に置かせてください。

;; APEL/FLIM/SEMI の頁群を CVS で管理し、幹の最新版が WWW 上に反映され
;; るようにすると良いかななんて思うんですが commiter の皆様、いかがで
;; しょうか？

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━



From Makoto.Nakagawa ＠ jp.compaq.com  Fri Jan 14 16:23:59 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 14 Jan 2000 16:23:59 +0900
Subject: line-move-ignore-invisible
Message-ID: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

例えば semi-setup.el にでも初期設定として下記のようなものが入っていると
初学者には優しいと思うのですがいかがでしょうか。

tm -> semi と 5年以上は利用してきましたが、つい最近になってこの変数の存
在をつきとめました。不便に感じる私のような者は少数派でしょうか。

(add-hook 'mime-edit-mode-hook (function (lambda ()
  (make-local-variable 'line-move-ignore-invisible)
  (setq line-move-ignore-invisible t)))

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000114/a021745b/attachment.pgp>

From nakaji ＠ tutrp.tut.ac.jp  Fri Jan 14 16:30:02 2000
From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki)
Date: 14 Jan 2000 16:30:02 +0900
Subject: line-move-ignore-invisible
In-Reply-To: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of "14 Jan 2000
 16:23:59 +0900")
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
Message-ID: <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>

>>>>> In [emacs-mime-ja : No.00319] 
>>>>>	Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) wrote:

中川さん> 例えば semi-setup.el にでも初期設定として下記のようなものが
中川さん> 入っていると初学者には優しいと思うのですがいかがでしょうか。

ある程度大きいファイルを base64 かなんかでくっつけたときに、その前のパー
トに、C-p でなかなか戻れない

ことがないようにすることができるんですね。

中川さん> tm -> semi と 5年以上は利用してきましたが、つい最近になって
中川さん> この変数の存在をつきとめました。不便に感じる私のような者は少
中川さん> 数派でしょうか。

私のような初学者には、とっても優しいと思います。
-- 
NAKAJI Hiroyuki (中治 弘行)



From yamaoka ＠ jpl.org  Fri Jan 14 16:37:48 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 14 Jan 2000 02:37:48 -0500 (EST)
Subject: line-move-ignore-invisible
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>
Message-ID: <yosuvh4xaysz.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00319] 
>>>>>	Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) wrote:

中川さん> (add-hook 'mime-edit-mode-hook (function (lambda ()
中川さん>   (make-local-variable 'line-move-ignore-invisible)
中川さん>   (setq line-move-ignore-invisible t)))

>>>>> In [emacs-mime-ja : No.00320] 
>>>>>	NAKAJI Hiroyuki <nakaji ＠ tutrp.tut.ac.jp> wrote:

中治さん> ある程度大きいファイルを base64 かなんかでくっつけたときに、
中治さん> その前のパートに、C-p でなかなか戻れない
中治さん> ことがないようにすることができるんですね。

なるほど。スムーズに up/down の移動ができることは便利だと思うのですが、
混乱の種にならないと良いですね。と言うのは、gnus の article header の
下の方にも invisible な行がどっさりあるのですが、うっかり copy & paste
してメールを送信したりするとエラいことになる、といった例があるからです。
-- 
~{I=8T?KC@~} <yamaoka ＠ jpl.org>



From Makoto.Nakagawa ＠ jp.compaq.com  Fri Jan 14 16:49:06 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 14 Jan 2000 16:49:06 +0900
Subject: line-move-ignore-invisible
In-Reply-To: Katsumi Yamaoka's message of "14 Jan 2000 02:37:48 -0500 (EST)"	<yosuvh4xaysz.fsf@jpl.org>
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
	<87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>
	<yosuvh4xaysz.fsf@jpl.org>
Message-ID: <14462.54514.102000.504691@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: line-move-ignore-invisible"
    on 00/01/14, Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

  > なるほど。スムーズに up/down の移動ができることは便利だと思うのですが、
  > 混乱の種にならないと良いですね。と言うのは、gnus の article header の
  > 下の方にも invisible な行がどっさりあるのですが、うっかり copy & paste
  > してメールを送信したりするとエラいことになる、といった例があるからです。

これは line-move-igore-invisible を設定しておかないことに「うっかり copy
& paste」を防ぐ効果があるということでしょうか。gnus を使ったことがありま
せんので、状況を把握できていません。

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000114/a84fcced/attachment.pgp>

From yamaoka ＠ jpl.org  Fri Jan 14 17:04:09 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 14 Jan 2000 03:04:09 -0500 (EST)
Subject: line-move-ignore-invisible
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
	<87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp> <yosuvh4xaysz.fsf@jpl.org>
	<14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
Message-ID: <yosuiu0xaxl2.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00322] 
>>>>>	Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) wrote:

山岡> と言うのは、gnus の article header の下の方にも invisible な行が
山岡> どっさりあるのですが、うっかり copy & paste してメールを送信した
山岡> りするとエラいことになる、といった例があるからです。

中川さん> これは line-move-igore-invisible を設定しておかないことに
中川さん> 「うっかり copy & paste」を防ぐ効果があるということでしょう
中川さん> か。

C-p や C-n でなかなか移動できないことが、「ここには何かある」というこ
とを意識させるものならばそういう効果が期待できるのですが、それは知って
いる者の言い分ですね。ごめんなさい。

中川さん> gnus を使ったことがありませんので、状況を把握できていません。

gnus で記事を読んでいるときに、見えているヘッダの最後の行とその直後の
空行の間には Received: などの普通は表示しないフィールドが存在していて、
line-move-igore-invisible を t にしておいても copy & paste の対象から
外れるわけではないことを申しました。

ところで Gnus 5.8 ではこの辺の事情が違っていまして、記事を表示している
バッファや message バッファに invisible な行は存在しないことになってい
ます。これも一つの見識ですね。

で、申し訳ありませんが、個人的には中川さんの code を盛り込むことに積極
的には賛成しません。もっともぼくは SEMI の maintainer ではないので、最
終的な判断をする立場にはありませんが。

;; MIME-Edit next generation では、こんなことをとやかく言う必要が無く
;; なるのではないか、という想像も少しあります。:-p
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From t90553 ＠ mail.ecc.u-tokyo.ac.jp  Fri Jan 14 20:20:32 2000
From: t90553 ＠ mail.ecc.u-tokyo.ac.jp (Yoshiki Hayashi)
Date: Fri, 14 Jan 2000 20:20:32 +0900
Subject: emy 1.13.0
Message-ID: <87d7r499xb.fsf@dp50.ecc.u-tokyo.ac.jp>

とうとう local の pressure に負けたので、SEMI 1.13 variant 
の一つ、EMY 1.13.0 を公開します。

特徴は MIME-View mode の拡張で、各 part において、c で code
を自動判別して表示、C-u c で coding-system の指定、i で
raw-text の表示、t で MIME type に応じた表示ができます。

Content-Disposition: attachment
を解釈するので、SEMI から送られた multipart message は
default では結構隠された状態で表示されます。

詳しくは、README.en と、ほとんど書かれていない emy.texi を参
照してください。

-- 
Yoshiki Hayashi



From Makoto.Nakagawa ＠ jp.compaq.com  Fri Jan 14 20:40:24 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 14 Jan 2000 20:40:24 +0900
Subject: line-move-ignore-invisible
In-Reply-To: Katsumi Yamaoka's message of "14 Jan 2000 03:04:09 -0500 (EST)"	<yosuiu0xaxl2.fsf@jpl.org>
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
	<87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>
	<yosuvh4xaysz.fsf@jpl.org>
	<14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
	<yosuiu0xaxl2.fsf@jpl.org>
Message-ID: <14463.2856.307000.446695@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: line-move-ignore-invisible"
    on 00/01/14, Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

  > で、申し訳ありませんが、個人的には中川さんの code を盛り込むことに積極
  > 的には賛成しません。

私も是非とも semi に漏り込みたいという訳ではありません。ただ、semi ユー
ザはどう思っているのか前々から気になっていただけです。個々の MUA なりで
対応する方針でもかまわないのですが、情報共有の意味でちと寂しい気がしまし
たので。

  > もっともぼくは SEMI の maintainer ではないので、最終的な判断をする立
  > 場にはありませんが。

とりあえずパッチの形にして、俎板の鯉となります。

-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: semi-setup.patch
型:         application/octet-stream
サイズ:     357 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000114/a287b319/attachment.obj>
-------------- next part --------------
2000-01-14  中川 誠  <Makoto.Nakagawa ＠ jp.compaq.com>

	* semi-setup.el: bind 'line-move-ignore-invisible' to t in
	mime-edit-mode-hook

-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000114/a287b319/attachment.pgp>

From s1021044 ＠ u-aizu.ac.jp  Sat Jan 15 04:14:59 2000
From: s1021044 ＠ u-aizu.ac.jp (Tashiron)
Date: 15 Jan 2000 04:14:59 +0900
Subject: Feature of variants
In-Reply-To: <htxiu0x1c33.fsf@mulelab3.etl.go.jp>
 (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's
 message of "14 Jan 2000 14:01:04 +0900")
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp> <86k8mnm21x.fsf@aqua.ocn.ne.jp> <wkemcuhnv6.wl@mature.din.or.jp> <86yab2ld5t.fsf@aqua.ocn.ne.jp> <htxpuwceje2.fsf@mulelab3.etl.go.jp> <86vh64y6ry.fsf@aqua.ocn.ne.jp> <htxiu24d2zs.fsf@mulelab3.etl.go.jp> <86bt7vkr56.fsf@aqua.ocn.ne.jp> <yosuwvqjawka.fsf@jpl.org> <rv33dt6gkuw.fsf@u-aizu.ac.jp> <htxiu0x1c33.fsf@mulelab3.etl.go.jp>
Message-ID: <rv33ds0jwi4.fsf@u-aizu.ac.jp>

たしろです．

In the message "Re: Feature of variants"
               <htxiu0x1c33.fsf ＠ mulelab3.etl.go.jp>
tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) さん wrote:
たしろ> あと，注意書(?)やご意見みたいなものなどありましたら参考に
たしろ> したいと思いますので何でも申し付けてください．m(..
守岡> mailto: は使わない方が良いと思います。

というわけで一応取り去っておきました．ですが，僕には
使わない方が良い理由というものが理解できていないので，
よろしければ教えてください．(DM でも全然構いません．)

たしろ> CSS を使って書いていますので，引き取って頂ける場合は
たしろ> http://www.u-aizu.ac.jp/~s1021044/base.css
たしろ> http://www.u-aizu.ac.jp/~s1021044/svariant.css
たしろ> も一緒に引き取ってくださいませ．m(..
守岡> よろしければ FLIM と SEMI の page に置かせてください。

こんなものでも使って頂けるんですね．(^^ ありがとうございます．

HTML や CSS に文法上の error はないはずですが，かなり
読みにくいコードになってしまってます．よろしければどなたか
手を加えて頂けると助かります．

それでは失礼します．
-- 

------ Univ. of Aizu ----------------------------------------
  School of Computer Science and Engineering       
   Name :   Hideo TASHIRO ( s1021044 ＠ u-aizu.ac.jp )
   Dept.:   Department of Computer Software        



From keiichi ＠ nanap.org  Sat Jan 15 11:55:59 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 15 Jan 2000 11:55:59 +0900
Subject: Feature of variants
In-Reply-To: <rv33ds0jwi4.fsf@u-aizu.ac.jp> (Tashiron's message of "15 Jan 2000 04:14:59 +0900")
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp> <86k8mnm21x.fsf@aqua.ocn.ne.jp>
 <wkemcuhnv6.wl@mature.din.or.jp> <86yab2ld5t.fsf@aqua.ocn.ne.jp>
 <htxpuwceje2.fsf@mulelab3.etl.go.jp> <86vh64y6ry.fsf@aqua.ocn.ne.jp>
 <htxiu24d2zs.fsf@mulelab3.etl.go.jp> <86bt7vkr56.fsf@aqua.ocn.ne.jp>
 <yosuwvqjawka.fsf@jpl.org> <rv33dt6gkuw.fsf@u-aizu.ac.jp>
 <htxiu0x1c33.fsf@mulelab3.etl.go.jp> <rv33ds0jwi4.fsf@u-aizu.ac.jp>
Message-ID: <uaem882m8.fsf@kei.nanap.org>

>>>>> emacs-mime-ja の No. 00326
>>>>> Message-Id: <rv33ds0jwi4.fsf ＠ u-aizu.ac.jp> で、
>>>>> "田代" == s1021044 ＠ u-aizu.ac.jp (Hideo TASHIRO)さま曰く...

守岡> mailto: は使わない方が良いと思います。

田代> というわけで一応取り去っておきました．ですが，僕には
田代> 使わない方が良い理由というものが理解できていないので，
田代> よろしければ教えてください．(DM でも全然構いません．)

ロボットに収集され易くなり、メイルアドレスが spam 対象として汚染される。

...ということではないかと思います。

;; Meadow の作者 himiさんはこれでで、アドレスが使い物にならなくなったそ
;; うです。

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From kose ＠ yk.NetLaputa.ne.jp  Sat Jan 15 23:56:41 2000
From: kose ＠ yk.NetLaputa.ne.jp (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori))
Date: 15 Jan 2000 23:56:41 +0900
Subject: Feature of variants
In-Reply-To: <uaem882m8.fsf@kei.nanap.org> (Keiichi Suzuki's message of "15 Jan 2000 11:55:59 +0900")
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp> <86k8mnm21x.fsf@aqua.ocn.ne.jp>
 <wkemcuhnv6.wl@mature.din.or.jp> <86yab2ld5t.fsf@aqua.ocn.ne.jp>
 <htxpuwceje2.fsf@mulelab3.etl.go.jp> <86vh64y6ry.fsf@aqua.ocn.ne.jp>
 <htxiu24d2zs.fsf@mulelab3.etl.go.jp> <86bt7vkr56.fsf@aqua.ocn.ne.jp>
 <yosuwvqjawka.fsf@jpl.org> <rv33dt6gkuw.fsf@u-aizu.ac.jp>
 <htxiu0x1c33.fsf@mulelab3.etl.go.jp> <rv33ds0jwi4.fsf@u-aizu.ac.jp>
 <uaem882m8.fsf@kei.nanap.org> <uaem882m8.fsf@kei.nanap.org>
Message-ID: <2000Jan15bt6nxu1i.kose@gnarl.yk.NetLaputa.ne.jp>

>>>>> In [emacs-mime-ja : No.00327] 
>>>>> “圭一” = Keiichi Suzuki <keiichi ＠ nanap.org>さん

守岡> mailto: は使わない方が良いと思います。

田代> というわけで一応取り去っておきました．ですが，僕には
田代> 使わない方が良い理由というものが理解できていないので，
田代> よろしければ教えてください．(DM でも全然構いません．)

圭一> ロボットに収集され易くなり、メイルアドレスが spam 対象として汚染される。

圭一> ...ということではないかと思います。

spam ですか...

なら http://lists.airs.net/semi-gnus/archive/ のようなメーリ
ングリストarchiveから収集されることも心配しないといけなくな
りますねぇ。

;; 世知辛い世の中になったもんだ。と年寄はいう...
-- 
こせき @ Emacs のページ作成中
http://www.NetLaputa.ne.jp/~kose/Emacs/
kose ＠ yk.NetLaputa.ne.jp



From kitame ＠ po.airs.net  Sun Jan 16 02:52:14 2000
From: kitame ＠ po.airs.net (Takuo KITAME / =?ISO-2022-JP?B?GyRCS0xMXBsoQiA=?=  =?ISO-2022-JP?B?GyRCQnNPOhsoQg==?=)
Date: Sun, 16 Jan 2000 02:52:14 +0900
Subject: Feature of variants
In-Reply-To: In your message of "15 Jan 2000 23:56:41 +0900"
	<2000Jan15bt6nxu1i.kose@gnarl.yk.NetLaputa.ne.jp>
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp>
	<86k8mnm21x.fsf@aqua.ocn.ne.jp>
	<wkemcuhnv6.wl@mature.din.or.jp>
	<86yab2ld5t.fsf@aqua.ocn.ne.jp>
	<htxpuwceje2.fsf@mulelab3.etl.go.jp>
	<86vh64y6ry.fsf@aqua.ocn.ne.jp>
	<htxiu24d2zs.fsf@mulelab3.etl.go.jp>
	<86bt7vkr56.fsf@aqua.ocn.ne.jp>
	<yosuwvqjawka.fsf@jpl.org>
	<rv33dt6gkuw.fsf@u-aizu.ac.jp>
	<htxiu0x1c33.fsf@mulelab3.etl.go.jp>
	<rv33ds0jwi4.fsf@u-aizu.ac.jp>
	<uaem882m8.fsf@kei.nanap.org>
	<2000Jan15bt6nxu1i.kose@gnarl.yk.NetLaputa.ne.jp>
Message-ID: <87n1q7uss1.wl@aqua.debian.gr.jp>


>>>>> In [emacs-mime-ja: 00328]
>>>>> "小関さん" == 小関 吉則 (KOSEKI Yoshinori) <kose ＠ yk.NetLaputa.ne.jp> wrote...
>>>>> In [emacs-mime-ja : No.00327] 
>>>>> “圭一” = Keiichi Suzuki <keiichi ＠ nanap.org>さん

守岡> mailto: は使わない方が良いと思います。

田代> というわけで一応取り去っておきました．ですが，僕には
田代> 使わない方が良い理由というものが理解できていないので，
田代> よろしければ教えてください．(DM でも全然構いません．)

圭一> ロボットに収集され易くなり、メイルアドレスが spam 対象として汚染される。

圭一> ...ということではないかと思います。

小関さん> spam ですか...

小関さん> なら http://lists.airs.net/semi-gnus/archive/ のようなメーリ
小関さん> ングリストarchiveから収集されることも心配しないといけなくな
小関さん> りますねぇ。

う、そういえば このアーカイブでは mailto: 使ってますね...
暇を見て修正しようかと思います。

-- 
Takuo KITAME / 北目 拓郎
  kitame ＠ po.airs.net



From s1021044 ＠ u-aizu.ac.jp  Sun Jan 16 03:38:55 2000
From: s1021044 ＠ u-aizu.ac.jp (Tashiron)
Date: 16 Jan 2000 03:38:55 +0900
Subject: Feature of variants
In-Reply-To: <uaem882m8.fsf@kei.nanap.org>
 (Keiichi Suzuki's message of "15 Jan 2000 11:55:59 +0900")
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp> <86k8mnm21x.fsf@aqua.ocn.ne.jp> <wkemcuhnv6.wl@mature.din.or.jp> <86yab2ld5t.fsf@aqua.ocn.ne.jp> <htxpuwceje2.fsf@mulelab3.etl.go.jp> <86vh64y6ry.fsf@aqua.ocn.ne.jp> <htxiu24d2zs.fsf@mulelab3.etl.go.jp> <86bt7vkr56.fsf@aqua.ocn.ne.jp> <yosuwvqjawka.fsf@jpl.org> <rv33dt6gkuw.fsf@u-aizu.ac.jp> <htxiu0x1c33.fsf@mulelab3.etl.go.jp> <rv33ds0jwi4.fsf@u-aizu.ac.jp> <uaem882m8.fsf@kei.nanap.org>
Message-ID: <rv3wvpbb2o0.fsf@u-aizu.ac.jp>

たしろです．

In the message "Re: Feature of variants"
               <uaem882m8.fsf ＠ kei.nanap.org>
Keiichi Suzuki <keiichi ＠ nanap.org> さん wrote:
田代> というわけで一応取り去っておきました．ですが，僕には
田代> 使わない方が良い理由というものが理解できていないので，
田代> よろしければ教えてください．(DM でも全然構いません．)
鈴木> ロボットに収集され易くなり、メイルアドレスが spam 対象として汚染される。
鈴木> ...ということではないかと思います。

そ，そうなのですか…  全然どこにも公開はしていないしリンクも
張られてはいないかとは思いますが，もしみなさんにご迷惑を
お掛けすることになってしまっていたら本当に申し訳ありません．
m(..;


-- 

------ Univ. of Aizu ----------------------------------------
  School of Computer Science and Engineering       
   Name :   Hideo TASHIRO ( s1021044 ＠ u-aizu.ac.jp )
   Dept.:   Department of Computer Software        



From himi ＠ bird.scphys.kyoto-u.ac.jp  Sun Jan 16 16:28:21 2000
From: himi ＠ bird.scphys.kyoto-u.ac.jp (Miyashita Hisashi (=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=))
Date: 16 Jan 2000 16:28:21 +0900
Subject: Feature of variants
In-Reply-To: <uaem882m8.fsf@kei.nanap.org>
 (Keiichi Suzuki's message of "15 Jan 2000 11:55:59 +0900")
References: <863dtcoxk5.fsf@aqua.ocn.ne.jp> <86k8mnm21x.fsf@aqua.ocn.ne.jp> <wkemcuhnv6.wl@mature.din.or.jp> <86yab2ld5t.fsf@aqua.ocn.ne.jp> <htxpuwceje2.fsf@mulelab3.etl.go.jp> <86vh64y6ry.fsf@aqua.ocn.ne.jp> <htxiu24d2zs.fsf@mulelab3.etl.go.jp> <86bt7vkr56.fsf@aqua.ocn.ne.jp> <yosuwvqjawka.fsf@jpl.org> <rv33dt6gkuw.fsf@u-aizu.ac.jp> <htxiu0x1c33.fsf@mulelab3.etl.go.jp> <rv33ds0jwi4.fsf@u-aizu.ac.jp> <uaem882m8.fsf@kei.nanap.org>
Message-ID: <u1z7iiiga.fsf@MILCH.meadow.scphys.kyoto-u.ac.jp>

ごみです。

Keiichi Suzuki <keiichi ＠ nanap.org> writes:

> 守岡> mailto: は使わない方が良いと思います。
> 
> 田代> というわけで一応取り去っておきました．ですが，僕には
> 田代> 使わない方が良い理由というものが理解できていないので，
> 田代> よろしければ教えてください．(DM でも全然構いません．)
> 
> ロボットに収集され易くなり、メイルアドレスが spam 対象として汚染される。
> 
> ...ということではないかと思います。
> 
> ;; Meadow の作者 himiさんはこれでで、アドレスが使い物にならなくなったそ
> ;; うです。

## 私はmaintainerだけど。ってのは、ちゃちゃかなぁ。
これで使い物にならなくなったのかどうかは、はっきりとはわかりませんが、
いつ頃からかわかりませんが、なんか知らんけど、himi ＠ bird.scphys.kyoto-u.ac.jp
あてに、やたらとメールがくるようになってしまいました。

おかげで、お金のもうけ方、とか、いい仕事がありますぜ、とか、すけべなおはなし
とか、ねずみ講、とか、安いコンピュータ、とか、なんかようわからんプロパガンダとか、
そんなメールがやたらときますね。(なら見るなという話はありますが、とりあえず、
summaryにあると見てしまう私。で、気分が悪くなる;_;)

というわけで、このアドレス宛てに、見知らぬ人からメールがきても、
defaultで、levelの低いグループに放り込まれます。
そのうちunsubscribeしてやろうかな。:-P

まあ、人によるかもしれません。どうやら、私は、SPAMメールに対する耐性が
弱いようなので、日に10通ぐらいでかなりうんざりします。

でも、メールシステムは再構築したので、もう、himi ＠ bird.scphys.kyoto-u.ac.jpに
何通SPAMがきても大丈夫。(これ以上来たら、見ないだけという話もある。^^;;;)

from himi



From keiichi ＠ nanap.org  Sun Jan 16 17:10:16 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 16 Jan 2000 17:10:16 +0900
Subject: mime-entity-*-buffer
Message-ID: <u1z7ih1xz.fsf@kei.nanap.org>

;; 書こうと思っていて、そのままになっていたのですが、動きが見えましたの
;; で... :-)

質問、または、要望です。

FLIM 1.13 では、 mime-entity-(body|header)-buffer というのがありますが、
今後とも header/body は、必ず buffer 内に保持しなければならないのでしょ
うか?

;; Nana-gnus 7 系列では、今のところ header は string として保持していま
;; す。(body は part 毎の buffer です。)

何かを parse するときなどは、 buffer を使った方が cost がかからないと思
いますので、 buffer 上で処理するというのは良いと思いますが、
mime-entity-with-(body/header)-buffer などというものをもうけて、 buffer
を使用する範囲を限定できるようにしていただけると助かります。

これからも buffer で行く、というのであれば、 Nana-gnus の方を変えますの
で、それはそれでも構いません。

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From tomo ＠ etl.go.jp  Sun Jan 16 17:57:04 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 16 Jan 2000 17:57:04 +0900
Subject: mime-entity-*-buffer
In-Reply-To: Keiichi Suzuki's message of "16 Jan 2000 17:10:16 +0900"
References: <u1z7ih1xz.fsf@kei.nanap.org>
Message-ID: <htx3drybdi7.fsf@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00332] 
>>>>>	"圭一" = Keiichi Suzuki <keiichi ＠ nanap.org> wrote:

圭一> 質問、または、要望です。

圭一> FLIM 1.13 では、 mime-entity-(body|header)-buffer というのがあり
圭一> ますが、今後とも header/body は、必ず buffer 内に保持しなければ
圭一> ならないのでしょうか?

既にそんなことはないはずです。（もしそういう制限があるとしたら bug で
す）

で、そのような制限がないために mime-entity-(body|header)-buffer がある
訳です。即ち、これらは buffer の存在を要求し、なかった場合に buffer を
生成する働きがあります。

;; あんまり表面化してないと思いますが、現在の仕様上の問題は、おそらく、
;; この extent が mm-backend の定義に依存していることだと思います。


圭一> 何かを parse するときなどは、 buffer を使った方が cost がかから
圭一> ないと思いますので、 buffer 上で処理するというのは良いと思います
圭一> が、mime-entity-with-(body/header)-buffer などというものをもうけ
圭一> て、 bufferを使用する範囲を限定できるようにしていただけると助か
圭一> ります。

上述したように、mime-entity-(body|header)-buffer を呼ぶまではこれらの
buffer の存在は保証されていません。で、問題はいつ消えるかが不明だとい
うことです。そういう観点では mime-entity-with-(body/header)-buffer は
良いと思います。ただおそらくこれは特殊形式なんだと思いますが、それを
macro で実装すると *.elc の可搬性上の問題が起こり易くなると思うので、
要らなくなった時点で mime-bury-entity-(body|header)-buffer を呼ぶ方が
良いかも知れません。（まあ、mime-entity-(body|header)-buffer と
mime-bury-entity-(body|header)-buffer に展開するように
mime-entity-with-(body/header)-buffer（私としては
mime-with-entity-(body/header)-buffer が好み）を定義するならそれでも良
いと思います）。


なお、もしこれらの拡張を実装するなら FLIM 1.14 に行ってください。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====



From keiichi ＠ nanap.org  Sun Jan 16 18:21:32 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 16 Jan 2000 18:21:32 +0900
Subject: mime-entity-*-buffer
In-Reply-To: <htx3drybdi7.fsf@mulelab3.etl.go.jp> (tomo@etl.go.jp's message of "16 Jan 2000 17:57:04 +0900")
References: <u1z7ih1xz.fsf@kei.nanap.org>
 <htx3drybdi7.fsf@mulelab3.etl.go.jp>
Message-ID: <uvh4ufk2r.fsf@kei.nanap.org>

>>>>> emacs-mime-ja の No. 00333
>>>>> Message-Id: <htx3drybdi7.fsf ＠ mulelab3.etl.go.jp> で、
>>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

圭一> FLIM 1.13 では、 mime-entity-(body|header)-buffer というのがあり
圭一> ますが、今後とも header/body は、必ず buffer 内に保持しなければ
圭一> ならないのでしょうか?

守岡> 既にそんなことはないはずです。（もしそういう制限があるとしたら bug で
守岡> す）

守岡> で、そのような制限がないために mime-entity-(body|header)-buffer がある
守岡> 訳です。即ち、これらは buffer の存在を要求し、なかった場合に buffer を
守岡> 生成する働きがあります。

これに関しては理解しているつもりですが...

圭一> 何かを parse するときなどは、 buffer を使った方が cost がかから
圭一> ないと思いますので、 buffer 上で処理するというのは良いと思います
圭一> が、mime-entity-with-(body/header)-buffer などというものをもうけ
圭一> て、 bufferを使用する範囲を限定できるようにしていただけると助か
圭一> ります。

守岡> 上述したように、mime-entity-(body|header)-buffer を呼ぶまではこれらの
守岡> buffer の存在は保証されていません。で、問題はいつ消えるかが不明だとい
守岡> うことです。そういう観点では mime-entity-with-(body/header)-buffer は
守岡> 良いと思います。ただおそらくこれは特殊形式なんだと思いますが、それを
守岡> macro で実装すると *.elc の可搬性上の問題が起こり易くなると思うので、
守岡> 要らなくなった時点で mime-bury-entity-(body|header)-buffer を呼ぶ方が
守岡> 良いかも知れません。（まあ、mime-entity-(body|header)-buffer と
守岡> mime-bury-entity-(body|header)-buffer に展開するように
守岡> mime-entity-with-(body/header)-buffer（私としては
守岡> mime-with-entity-(body/header)-buffer が好み）を定義するならそれでも良
守岡> いと思います）。

現実問題としては、消すタイミングがつかめない限り、一旦 buffer を生成した
ら、表示しているメッセージを破棄するまで、消すわけには行きませんので、結
果的には buffer で管理するしかないのではないかと思いました。

それでも、良いと言えば良いのですが、 buffer があまりたくさんできると、うっ
とうしいですので。 ^^;;;

守岡> なお、もしこれらの拡張を実装するなら FLIM 1.14 に行ってください。

了解しました。

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From tomo ＠ etl.go.jp  Sun Jan 16 18:49:26 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 16 Jan 2000 18:49:26 +0900
Subject: mime-entity-*-buffer
In-Reply-To: Keiichi Suzuki's message of "16 Jan 2000 18:21:32 +0900"
References: <u1z7ih1xz.fsf@kei.nanap.org>
 <htx3drybdi7.fsf@mulelab3.etl.go.jp> <uvh4ufk2r.fsf@kei.nanap.org>
Message-ID: <htxu2kel521.fsf@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00334] 
>>>>>	"圭一" = Keiichi Suzuki <keiichi ＠ nanap.org> wrote:

守岡> 上述したように、mime-entity-(body|header)-buffer を呼ぶまではこ
守岡> れらのbuffer の存在は保証されていません。で、問題はいつ消えるか
守岡> が不明だということです。そういう観点では 
守岡> mime-entity-with-(body/header)-buffer は良いと思います。ただおそ
守岡> らくこれは特殊形式なんだと思いますが、それをmacro で実装すると 
守岡> *.elc の可搬性上の問題が起こり易くなると思うので、要らなくなった
守岡> 時点で mime-bury-entity-(body|header)-buffer を呼ぶ方が良いかも
守岡> 知れません。（まあ、mime-entity-(body|header)-buffer と
守岡> mime-bury-entity-(body|header)-buffer に展開するように
守岡> mime-entity-with-(body/header)-buffer（私としては
守岡> mime-with-entity-(body/header)-buffer が好み）を定義するならそれ
守岡> でも良いと思います）。

圭一> 現実問題としては、消すタイミングがつかめない限り、一旦 buffer を
圭一> 生成したら、表示しているメッセージを破棄するまで、消すわけには行
圭一> きませんので、結 果的には buffer で管理するしかないのではないか
圭一> と思いました。

圭一> それでも、良いと言えば良いのですが、 buffer があまりたくさんでき
圭一> ると、うっとうしいですので。 ^^;;;

;; Emacs が不要 buffer を回収してくれれば良いんでしょうが。(^_^;

この approach で行くとするなら、FLIM に FLIM で作成された一次 buffer
を回収する機構を作るというのが良いかも知れませんね。

;; でも面倒そう。(^_^;

あるいは mime-entity-(body|header)-buffer を廃止（もしくは存在を保証し
ないように）するというのはいかがでしょうか？これはそもそも FLIM API が
十分に整備されていない場合の最期の手段という側面が強い訳ですが、SEMI 
で使っている部分を眺めた限りでは無くても問題ない気がしました。また、こ
れが無くても最悪 mime-insert-entity を使えば parse などは出来る訳です
し。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====



From keiichi ＠ nanap.org  Sun Jan 16 19:12:50 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 16 Jan 2000 19:12:50 +0900
Subject: mime-entity-*-buffer
In-Reply-To: <htxu2kel521.fsf@mulelab3.etl.go.jp> (tomo@etl.go.jp's message of "16 Jan 2000 18:49:26 +0900")
References: <u1z7ih1xz.fsf@kei.nanap.org>
 <htx3drybdi7.fsf@mulelab3.etl.go.jp> <uvh4ufk2r.fsf@kei.nanap.org>
 <htxu2kel521.fsf@mulelab3.etl.go.jp>
Message-ID: <ur9fi8gv1.fsf@kei.nanap.org>

>>>>> emacs-mime-ja の No. 00335
>>>>> Message-Id: <htxu2kel521.fsf ＠ mulelab3.etl.go.jp> で、
>>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

圭一> それでも、良いと言えば良いのですが、 buffer があまりたくさんでき
圭一> ると、うっとうしいですので。 ^^;;;

守岡> ;; Emacs が不要 buffer を回収してくれれば良いんでしょうが。(^_^;

;; どうやってやるんだろう ^^;;;;

守岡> この approach で行くとするなら、FLIM に FLIM で作成された一次 buffer
守岡> を回収する機構を作るというのが良いかも知れませんね。

守岡> ;; でも面倒そう。(^_^;

守岡> あるいは mime-entity-(body|header)-buffer を廃止（もしくは存在を保
守岡> 証しないように）するというのはいかがでしょうか？これはそもそも 
守岡> FLIM API が十分に整備されていない場合の最期の手段という側面が強い
守岡> 訳ですが、SEMI で使っている部分を眺めた限りでは無くても問題ない気
守岡> がしました。また、これが無くても最悪 mime-insert-entity を使えば 
守岡> parse などは出来る訳ですし。

そうなのです、私もなくても済みそうだと思ったのです。
;; でも、何か深遠なわけでもあるのかなと。 :-)

;; 今日はこれにて閉店します。
-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From Makoto.Nakagawa ＠ jp.compaq.com  Mon Jan 17 11:22:42 2000
From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?=  =?ISO-2022-JP?B?GyRCQD8bKEI=?=)
Date: 17 Jan 2000 11:22:42 +0900
Subject: pgg-pgp5
In-Reply-To: =?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of
 "12 Jan 2000 17:21:28
 +0900"<14460.14728.475000.340576@manakagawa-nt.osa.dec.com>
Message-ID: <14466.31986.259000.5081@manakagawa-nt.osa.dec.com>

中川＠コンパック(株)です。

In message "Re: pgg-pgp5"
    on 00/01/12, 中川 誠 <Makoto.Nakagawa ＠ jp.compaq.com> wrote:

  >> この際、GnuPG とは全く別の実装にしたほうが良いのではと思います。
 
  > 確かに GnuPG の verify のようにバッファを解析して正否を判断するのがよさ
  > そうですね。ちょいと挑戦してみます。

GnuPG と別実装の意味が分らなかったのですが、verify についてバッファを解
析して正否を判定するようにしました。

結局は pgg-*-process-region に引き数を追加するという安直な方法を採りまし
た。

pgg-pgp.el と pgg-pgp.el についてのパッチです。(前回の修正分も含んでいます)

-------------- next part --------------
2000-01-17  中川 誠  <Makoto.Nakagawa ＠ jp.compaq.com>

	* pgg-pgp.el (pgg-pgp-process-region): Optional 6th argument not
	to process-send-region.

	* pgg-pgp5.el (pgg-pgp5-process-region): Ditto.

	* pgg-pgp.el (verify-region): Undo last change to use
	pgg-*-process-region with optional 6th argument.  Analize
	process output to see whether verify successed or not.

	* pgg-pgp5.el (verify-region): Ditto.

-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: pgg-pgp.patch
型:         application/octet-stream
サイズ:     2343 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000117/b81cf1bf/attachment.obj>
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: pgg-pgp5.patch
型:         application/octet-stream
サイズ:     1940 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000117/b81cf1bf/attachment-0001.obj>
-------------- next part --------------
-- 
/***   Compaq Computer K.K.                        ***/
/***   Network and Systems Integration Servieces   ***/
/***   Nakagawa, Makoto（中川　誠）                ***/
/*  F6 E1 41 25 49 DF A8 82  D4 94 4F 0C 95 6B D7 57 */
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型:         application/pgp-signature
サイズ:     348 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000117/b81cf1bf/attachment.pgp>

From tomo ＠ etl.go.jp  Tue Jan 18 18:20:45 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 18 Jan 2000 18:20:45 +0900
Subject: key-binding of mime-view-mode (about Re: emy 1.13.0)
In-Reply-To: Yoshiki Hayashi's message of "Fri, 14 Jan 2000 20:20:32 +0900"
References: <87d7r499xb.fsf@dp50.ecc.u-tokyo.ac.jp>
Message-ID: <htxk8l7enwy.fsf@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00324] 
>>>>>	"Yoshiki" = Yoshiki Hayashi <t90553 ＠ mail.ecc.u-tokyo.ac.jp> wrote:

Yoshiki> とうとう local の pressure に負けたので、SEMI 1.13 variant 
Yoshiki> の一つ、EMY 1.13.0 を公開します。

Yoshiki> 特徴は MIME-View mode の拡張で、各 part において、c で code
Yoshiki> を自動判別して表示、C-u c で coding-system の指定、i で
Yoshiki> raw-text の表示、t で MIME type に応じた表示ができます。

Yoshiki> Content-Disposition: attachment
Yoshiki> を解釈するので、SEMI から送られた multipart message は
Yoshiki> default では結構隠された状態で表示されます。

Yoshiki> 詳しくは、README.en と、ほとんど書かれていない emy.texi を参
Yoshiki> 照してください。

いずれも懸案事項ですね。ありがとうございます。

REMI 1.14 (will be SEMI 1.14) でも同様の事項を実装するつもりなんですが、
ちょっと考えないといけないことがあります。

Content-Disposition の設定は mime-preview-condition の設定なのでさっさ
と変えれば良いだけですが、key-binding についてはちょっと体系だって考え
たいと思います。

REMI 1.14 では文字符号の他にも button, header, body の表示・非表示を
対話的に設定できるようにしようと思っています（必要なら、これ以外の表示
に関わる設定も）。ところが、mime-view-mode に設定する場合、各 MUA の
key-binding にぶつかりやすくなります。例えば、c は RMAIL mode では

c	Continue composing outgoing message started before.

とぶつかります。

抜本的には MUA 毎に mime-view-mode の key-binding を変えやすくする機構
を考慮するのが良いと思います。例えば、mime-view-mode には
default-binding だけにして、major-mode を key に（あるいは実行状況によっ
て）dispatch する command を束縛するとか。あるいは、MUA 毎に keymap を
定義する機構を作るとか。

また、抜本的な解決を図らない場合（あるいは、図るとしても MUA 毎に全然
違う操作体系なのは良くないと思うので）、なるだけぶつかりにくい
key-binding を行うのが良いと思います。具体的には alphabet 1 文字系は避
け、C-c C-CHAR もしくはその他の prefix を付けたものを使うのが良いので
はないかと思います。

この案に従う場合、CHAR なものは現状で凍結（あるいは MUA のとぶつかり有
害だと思われるものは C-c 等に移動）します。新設するものは C-c C-CHAR
等とし、SEMI 1.14 では

C-c C-v b	     button を表示する
C-c C-v h	     header を表示する
C-c C-v c	     内容を表示する
C-c C-h b	     button を隠す
C-c C-h h	     header を隠す
C-c C-h c	     内容を隠す
C-c C-d		     表示単位を隠す
C-c C-s c	     文字符号を強制変更する (自動判定結果が default)
C-c C-s m	     表示法 (or media-type) の強制変更
C-c C-s e	     Content-Transfer-Encoding の強制変更

などを追加するのはいかがでしょうか？

3 stroke は長いでしょうか？また、表示・非表示関係は toggle の方が良い
でしょうか？

御意見よろしくお願いします。

;; 思うに、key-binding は可能な限り、各枝で共通にするのが良いのではな
;; いかと思います。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====



From tomo ＠ etl.go.jp  Tue Jan 18 19:29:15 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 18 Jan 2000 19:29:15 +0900
Subject: line-move-ignore-invisible
In-Reply-To: Katsumi Yamaoka's message of "14 Jan 2000 03:04:09 -0500 (EST)"
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp> <yosuvh4xaysz.fsf@jpl.org>
 <14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
 <yosuiu0xaxl2.fsf@jpl.org>
Message-ID: <htxembfekqs.fsf@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00323] 
>>>>>	"山岡" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

山岡> ;; MIME-Edit next generation では、こんなことをとやかく言う必要
山岡> ;; が無くなるのではないか、という想像も少しあります。:-p

個人的には一応そのつもりではあるのですが、問題は mmediting.el の開発が
全然進んでいないことにあります。

ところで、個人的には SEMI 1.13 系列の新しい版を release する予定は無い
のですが、もし SEMI 1.14.0 が待てないということであれば、現状の REMI
1.14 に必要な改良を行った上で SEMI 1.14 として release し、MIME-Edit
next generation は REMI 1.15 で行うということにしましょう。

;; 待てないという声が出なければ、予定通り、MIME-Edit next generation 
;; に移行後、REMI 1.14 を SEMI 1.l4 (or 1.90) にするという方向で行こう
;; と思います。mime-view 関連が落ち着いたら一度 REMI 1.14.0 を release 
;; する予定です。

;;; 現状の REMI 1.14 の中身は EMIKO 1.13 を元に表示状況の計算法を変え
;;; たものになっています。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====



From teranisi ＠ gohome.org  Wed Jan 19 09:24:59 2000
From: teranisi ＠ gohome.org (Yuuichi Teranishi)
Date: Wed, 19 Jan 2000 09:24:59 +0900
Subject: key-binding of mime-view-mode (about Re: emy 1.13.0)
In-Reply-To: In your message of "18 Jan 2000 18:20:45 +0900"
	<htxk8l7enwy.fsf@mulelab3.etl.go.jp>
References: <87d7r499xb.fsf@dp50.ecc.u-tokyo.ac.jp>
	<htxk8l7enwy.fsf@mulelab3.etl.go.jp>
Message-ID: <fz4scaaox0.wl@gohome.org>

At 18 Jan 2000 18:20:45 +0900,
守岡 知彦 / MORIOKA Tomohiko <tomo ＠ etl.go.jp> wrote:
> 
> C-c C-v b	     button を表示する
> C-c C-v h	     header を表示する
> C-c C-v c	     内容を表示する
> C-c C-h b	     button を隠す
> C-c C-h h	     header を隠す
> C-c C-h c	     内容を隠す
> C-c C-d		     表示単位を隠す
> C-c C-s c	     文字符号を強制変更する (自動判定結果が default)
> C-c C-s m	     表示法 (or media-type) の強制変更
> C-c C-s e	     Content-Transfer-Encoding の強制変更
> 
> などを追加するのはいかがでしょうか？
> 
> 3 stroke は長いでしょうか？また、表示・非表示関係は toggle の方が良い
> でしょうか？

必要なら 1 char のショートキーバインドを MUA 毎に定義すればいいので、
デフォルトキーバインドは３ストロークでもいいと思います。
また、表示制御はトグルがいいと思います。

--
Yuuichi Teranishi (寺西裕一) <teranisi ＠ gohome.org>
PGP 5.0i Public Key: http://www.gohome.org/pgp5/teranisi.key
"There will be an answer, let it be..."



From teranisi ＠ gohome.org  Wed Jan 19 09:30:09 2000
From: teranisi ＠ gohome.org (Yuuichi Teranishi)
Date: Wed, 19 Jan 2000 09:30:09 +0900
Subject: line-move-ignore-invisible
In-Reply-To: In your message of "18 Jan 2000 19:29:15 +0900"
	<htxembfekqs.fsf@mulelab3.etl.go.jp>
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
	<87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>
	<yosuvh4xaysz.fsf@jpl.org>
	<14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
	<yosuiu0xaxl2.fsf@jpl.org>
	<htxembfekqs.fsf@mulelab3.etl.go.jp>
Message-ID: <fz3druaooe.wl@gohome.org>

At 18 Jan 2000 19:29:15 +0900,
守岡 知彦 / MORIOKA Tomohiko <tomo ＠ etl.go.jp> wrote:
> 
> 個人的には一応そのつもりではあるのですが、問題は mmediting.el の開発が
> 全然進んでいないことにあります。
> 
> ところで、個人的には SEMI 1.13 系列の新しい版を release する予定は無い
> のですが、もし SEMI 1.14.0 が待てないということであれば、現状の REMI
> 1.14 に必要な改良を行った上で SEMI 1.14 として release し、MIME-Edit
> next generation は REMI 1.15 で行うということにしましょう。

リリースを望みます。
また、FLIM も各種仏典結集版が出てほしいです。

--
Yuuichi Teranishi (寺西裕一) <teranisi ＠ gohome.org>
PGP 5.0i Public Key: http://www.gohome.org/pgp5/teranisi.key
"Only time will tell if I am right or I am wrong..."



From okada ＠ opaopa.org  Wed Jan 19 10:30:59 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Wed, 19 Jan 2000 10:30:59 +0900
Subject: line-move-ignore-invisible
In-Reply-To: In your message of "Wed, 19 Jan 2000 09:30:09 +0900"
	<fz3druaooe.wl@gohome.org>
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
	<87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>
	<yosuvh4xaysz.fsf@jpl.org>
	<14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
	<yosuiu0xaxl2.fsf@jpl.org>
	<htxembfekqs.fsf@mulelab3.etl.go.jp>
	<fz3druaooe.wl@gohome.org>
Message-ID: <sgya9mx2y4.wl@vlsi.kuee.kyoto-u.ac.jp>

おかだです。

In the message "Re: line-move-ignore-invisible"
               <fz3druaooe.wl ＠ gohome.org>
Yuuichi Teranishi <teranisi ＠ gohome.org> wrote:

> また、FLIM も各種仏典結集版が出てほしいです。

SLIMについては，SASLのAPIが確定していないため，
本体に統合できる状態ではありません．
;; 修論が終ったらどうにかなる予定です…

勝手にToDo.
・KERBEROS_V4とGSSAPIの対応．
・DIGEST-MD5の機能補完
・SCRAM-MD5のデバック

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From tomo ＠ etl.go.jp  Wed Jan 19 18:39:46 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 19 Jan 2000 18:39:46 +0900
Subject: SEMI 1.14 (Re: line-move-ignore-invisible)
In-Reply-To: Yuuichi Teranishi's message of "Wed, 19 Jan 2000 09:30:09 +0900"
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp> <yosuvh4xaysz.fsf@jpl.org>
 <14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
 <yosuiu0xaxl2.fsf@jpl.org> <htxembfekqs.fsf@mulelab3.etl.go.jp>
 <fz3druaooe.wl@gohome.org>
Message-ID: <htxaem2z9gd.fsf_-_@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00341] 
>>>>>	"寺西" = Yuuichi Teranishi <teranisi ＠ gohome.org> さま曰く：

寺西> > ところで、個人的には SEMI 1.13 系列の新しい版を release する予
寺西> > 定は無いのですが、もし SEMI 1.14.0 が待てないということであれ
寺西> > ば、現状の REMI 1.14 に必要な改良を行った上で SEMI 1.14 として 
寺西> > release し、MIME-Edit next generation は REMI 1.15 で行うとい
寺西> > うことにしましょう。

寺西> リリースを望みます。

MIME-Edit next generation なしの REMI 1.14 を SEMI 1.14 として release
ということでしょうか？それとも SEMI 1.13 の新版を release ということで
しょうか？

寺西> また、FLIM も各種仏典結集版が出てほしいです。

そうですね。ただ、私としては自分で結集する余裕は無いので、flim-1_14 枝
を作ってどなたかがやってくだされば release します。

MIME-Edit next generation なしで SEMI 1.14 を出すなら特に判りにくくは
無いと思いますし。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====



From tomo ＠ etl.go.jp  Wed Jan 19 18:45:44 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 19 Jan 2000 18:45:44 +0900
Subject: key-binding of mime-view-mode (about Re: emy 1.13.0)
In-Reply-To: Yuuichi Teranishi's message of "Wed, 19 Jan 2000 09:24:59 +0900"
References: <87d7r499xb.fsf@dp50.ecc.u-tokyo.ac.jp>
 <htxk8l7enwy.fsf@mulelab3.etl.go.jp> <fz4scaaox0.wl@gohome.org>
Message-ID: <htx7lh6z96f.fsf@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00340] 
>>>>>	"寺西" = Yuuichi Teranishi <teranisi ＠ gohome.org> wrote:

寺西> > C-c C-v b	     button を表示する
寺西> > C-c C-v h	     header を表示する
寺西> > C-c C-v c	     内容を表示する
寺西> > C-c C-h b	     button を隠す
寺西> > C-c C-h h	     header を隠す
寺西> > C-c C-h c	     内容を隠す
寺西> > C-c C-d		     表示単位を隠す
寺西> > C-c C-s c	     文字符号を強制変更する (自動判定結果が default)
寺西> > C-c C-s m	     表示法 (or media-type) の強制変更
寺西> > C-c C-s e	     Content-Transfer-Encoding の強制変更
寺西> > 
寺西> > などを追加するのはいかがでしょうか？
寺西> > 
寺西> > 3 stroke は長いでしょうか？また、表示・非表示関係は toggle の
寺西> > 方が良いでしょうか？

寺西> 必要なら 1 char のショートキーバインドを MUA 毎に定義すればいい
寺西> ので、デフォルトキーバインドは３ストロークでもいいと思います。

そうですね。じゃあそういうことで。

寺西> また、表示制御はトグルがいいと思います。

最初はそうしてたんですが、やっぱその方が良いですかね。

その後、特に、header に関して、どばっと表示してから、C-c C-d で欄単位
に削るなんてことを考えたりしたので、toggle は良くないかなと思ったんで
すが。でも、このノリで行くなら、button, header, body などとにかく全部
表示する command + C-c C-d で削るという体系の方が良いかも知れませんね。

;; あるいは、この系統は header 限定の方が良いかな？

;; ふと思ったけども、C-c C-d よりも C-c C-k で、C-c C-y で張り付けも出
;; 来て、これで sort の設定も出来てしまう方が良いかも知れない。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====



From teranisi ＠ gohome.org  Wed Jan 19 20:24:50 2000
From: teranisi ＠ gohome.org (Yuuichi Teranishi)
Date: Wed, 19 Jan 2000 20:24:50 +0900
Subject: SEMI 1.14 (Re: line-move-ignore-invisible)
In-Reply-To: In your message of "19 Jan 2000 18:39:46 +0900"
	<htxaem2z9gd.fsf_-_@mulelab3.etl.go.jp>
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
	<87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp>
	<yosuvh4xaysz.fsf@jpl.org>
	<14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
	<yosuiu0xaxl2.fsf@jpl.org>
	<htxembfekqs.fsf@mulelab3.etl.go.jp>
	<fz3druaooe.wl@gohome.org>
	<htxaem2z9gd.fsf_-_@mulelab3.etl.go.jp>
Message-ID: <fzwvp68fst.wl@gohome.org>

At 19 Jan 2000 18:39:46 +0900,
守岡 知彦 / MORIOKA Tomohiko <tomo ＠ etl.go.jp> wrote:
> 
> 寺西> リリースを望みます。
> 
> MIME-Edit next generation なしの REMI 1.14 を SEMI 1.14 として release
> ということでしょうか？それとも SEMI 1.13 の新版を release ということで
> しょうか？

あ、舌足らずですみません。
前者のつもりでした。

> 寺西> また、FLIM も各種仏典結集版が出てほしいです。
> 
> そうですね。ただ、私としては自分で結集する余裕は無いので、flim-1_14 枝
> を作ってどなたかがやってくだされば release します。

もしかして、
slim がまだ本体に合流できないということであれば、
flim-1_13-rfc2231 だけではないでしょうか？

--
Yuuichi Teranishi (寺西裕一) <teranisi ＠ gohome.org>
PGP 5.0i Public Key: http://www.gohome.org/pgp5/teranisi.key
"The love you take is equal to the love you make..."



From keiichi ＠ nanap.org  Thu Jan 20 09:52:29 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 20 Jan 2000 09:52:29 +0900
Subject: line-move-ignore-invisible
In-Reply-To: <htxembfekqs.fsf@mulelab3.etl.go.jp> (tomo@etl.go.jp's message of "18 Jan 2000 19:29:15 +0900")
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp> <yosuvh4xaysz.fsf@jpl.org>
 <14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
 <yosuiu0xaxl2.fsf@jpl.org> <fzwvp68fst.wl@gohome.org>
 <htxembfekqs.fsf@mulelab3.etl.go.jp>
Message-ID: <upuuxmunm.fsf@kei.nanap.org>

;; 無理がたたって、一日寝ていました。 ;_;

>>>>> emacs-mime-ja の No. 00339
>>>>> Message-Id: <htxembfekqs.fsf ＠ mulelab3.etl.go.jp> で、
>>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

守岡> ところで、個人的には SEMI 1.13 系列の新しい版を release する予定は無い
守岡> のですが、もし SEMI 1.14.0 が待てないということであれば、現状の REMI
守岡> 1.14 に必要な改良を行った上で SEMI 1.14 として release し、MIME-Edit
守岡> next generation は REMI 1.15 で行うということにしましょう。

SEMI 1.13 では nana7 の今後の方針を決定できませんので、「必要な改良」の
中に mime-entity-\(.*-\)?buffer の件も含まれているのであれば、この方針で
お願いしたいと思います。

;; MIME-Edit next generation の方は、どうなるにせよガラッと\(変えなけれ
;; ばならない\|たい\)と思いますので、ゆっくり待ちます。

守岡> ;; 待てないという声が出なければ、予定通り、MIME-Edit next generation 
守岡> ;; に移行後、REMI 1.14 を SEMI 1.l4 (or 1.90) にするという方向で行こう
守岡> ;; と思います。mime-view 関連が落ち着いたら一度 REMI 1.14.0 を release 
守岡> ;; する予定です。

;; 1.90 に一票。 :-)

;; ところで、 Emacs 21 に含めるという FLIM / SEMI はどのバージョンにする
;; のでしょうか?

>>>>> emacs-mime-ja の No. 00345
>>>>> Message-Id: <fzwvp68fst.wl ＠ gohome.org> で、
>>>>> "寺西" == Yuuichi Teranishi <teranisi ＠ gohome.org>さま曰く...

>> 寺西> また、FLIM も各種仏典結集版が出てほしいです。
>> 
>> そうですね。ただ、私としては自分で結集する余裕は無いので、flim-1_14 枝
>> を作ってどなたかがやってくだされば release します。

寺西> もしかして、
寺西> slim がまだ本体に合流できないということであれば、
寺西> flim-1_13-rfc2231 だけではないでしょうか？

上に書いた私の希望が受け入れられるとすると、これだけではなくなります。

工数的にはそんなに大きなものではないと思いますが、 FLIM API の変更として
は、小さなものではないと思います。

そう考えると、「待てない」という要求には対応できないような気もしなくもあ
りません、 1.14 は「仏典結集版」として、 API の変更は最小限に抑えるとい
うのも良いかとも思いますので、私の希望は弱いものと考えていただいて結構で
す。

;; flim-1_13-rfc2231 で追加した部分も mime-entity class の class 関数と
;; して、実装し直したい、既存のものも含め、各 parser の方も class 関数に
;; 含めたい。... と言い出すときりがありませんが、現在時間がまるでとれま
;; せん。 ;_;
-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From tomo ＠ etl.go.jp  Thu Jan 20 14:58:11 2000
From: tomo ＠ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 20 Jan 2000 14:58:11 +0900
Subject: line-move-ignore-invisible
In-Reply-To: Keiichi Suzuki's message of "20 Jan 2000 09:52:29 +0900"
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp> <yosuvh4xaysz.fsf@jpl.org>
 <14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
 <yosuiu0xaxl2.fsf@jpl.org> <fzwvp68fst.wl@gohome.org>
 <htxembfekqs.fsf@mulelab3.etl.go.jp> <upuuxmunm.fsf@kei.nanap.org>
Message-ID: <htxwvp5p9n0.fsf@mulelab3.etl.go.jp>

>>>>> In [emacs-mime-ja : No.00346] 
>>>>>	"圭一" = Keiichi Suzuki <keiichi ＠ nanap.org> wrote:

圭一> ;; 無理がたたって、一日寝ていました。 ;_;

;; お大事に。(って、もう回復されているのかな）

圭一> >>>>> emacs-mime-ja の No. 00339
圭一> >>>>> Message-Id: <htxembfekqs.fsf ＠ mulelab3.etl.go.jp> で、
圭一> >>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

守岡> ところで、個人的には SEMI 1.13 系列の新しい版を release する予定
守岡> は無いのですが、もし SEMI 1.14.0 が待てないということであれば、
守岡> 現状の REMI 1.14 に必要な改良を行った上で SEMI 1.14 として 
守岡> release し、MIME-Edit next generation は REMI 1.15 で行うという
守岡> ことにしましょう。

圭一> SEMI 1.13 では nana7 の今後の方針を決定できませんので、「必要な
圭一> 改良」の中に mime-entity-\(.*-\)?buffer の件も含まれているのであ
圭一> れば、この方針でお願いしたいと思います。

とりあえず、SEMI 1.14 ではこれらを使わないという仕様にし、順次、書き換
えを行うということで良いでしょうか？


圭一> ;; MIME-Edit next generation の方は、どうなるにせよガラッと\(変
圭一> ;; えなければならない\|たい\)と思いますので、ゆっくり待ちます。

守岡> ;; 待てないという声が出なければ、予定通り、MIME-Edit next
守岡> ;; generation に移行後、REMI 1.14 を SEMI 1.l4 (or 1.90) にする
守岡> ;; という方向で行こうと思います。mime-view 関連が落ち着いたら一
守岡> ;; 度 REMI 1.14.0 を release する予定です。

圭一> ;; 1.90 に一票。 :-)

;; じゃあ、その時はそういうことで。

;; なんとなく、mmediting.el をえいやっと書いてしまいたい機運も高まって
;; はいるので、表示関係よりも先にこっちが出来てしまう可能性もあります
;; が。(^_^;


圭一> ;; ところで、 Emacs 21 に含めるという FLIM / SEMI はどのバージョ
圭一> ;; ンにするのでしょうか?

;; 個人的には SEMI 2.0 にしたいのですが。

;; APEL 問題の返事を Gerd さんに送りそびれたまま、止まっています。
;; (^_^;; 今月中には返事する予定です。


圭一> >>>>> emacs-mime-ja の No. 00345
圭一> >>>>> Message-Id: <fzwvp68fst.wl ＠ gohome.org> で、
圭一> >>>>> "寺西" == Yuuichi Teranishi <teranisi ＠ gohome.org>さま曰く...

圭一> >> 寺西> また、FLIM も各種仏典結集版が出てほしいです。
圭一> >> 
圭一> >> そうですね。ただ、私としては自分で結集する余裕は無いので、
圭一> >> flim-1_14 枝を作ってどなたかがやってくだされば release します。

寺西> もしかして、
寺西> slim がまだ本体に合流できないということであれば、
寺西> flim-1_13-rfc2231 だけではないでしょうか？

圭一> 上に書いた私の希望が受け入れられるとすると、これだけではなくなり
圭一> ます。

圭一> 工数的にはそんなに大きなものではないと思いますが、 FLIM API の変
圭一> 更としては、小さなものではないと思います。

圭一> そう考えると、「待てない」という要求には対応できないような気もし
圭一> なくもありません、 1.14 は「仏典結集版」として、 API の変更は最
圭一> 小限に抑えるというのも良いかとも思いますので、私の希望は弱いもの
圭一> と考えていただいて結構です。

とりあえず、FLIM 1.14 実装では mime-entity-\(.*-\)?buffer を obsolete
宣言するという方向ではいかがでしょうか？


圭一> ;; flim-1_13-rfc2231 で追加した部分も mime-entity class の class 
圭一> ;; 関数として、実装し直したい、既存のものも含め、各 parser の方
圭一> ;; も class 関数に含めたい。... と言い出すときりがありませんが、
圭一> ;; 現在時間がまるでとれません。 ;_;

flim-1_13-rfc2231 関連の整理は API に絡む問題なので API だけでも何とか
したいですが、これに手を出しはじめると収集付かなくなる気がするのと、個
人的に今 FLIM 機運が低いので (^_^;;;（冬休みにちゃおに手をひっかかれた
し（痛かった）；ちなみに妹は両手をもっとひどくやられていたらしい）、
とりあえず SEMI の問題を片付けたいと思っています。

;; でも、flim-1_13-rfc2231 は気になってはいるんです。でも、emacs での
;; 言語の扱いとも絡むのと、今、某ファンドマネージャーの現実逃避である、
;; たまごいじりが止まらなくなっているようで、
;; language/LEIM/its/egg/quail/writing-system/script/CES
;; (coding-system)/CCS (charset) の関係が Mule ではむちゃくちゃなのに
;; 腹を立てて（ちょうど、XEmacs-Mule で Hrvoje さんが Mule is broken!
;; と叫んでいたのと同様に）このへんの関係をとりあえず表にまとめて、半
;; 田さんと協力しながら（を罵倒しながら(^_^;;;）最終的にはもうちょっと
;; すっきりした木構造かネットワーク構造に再編しようとしている（かも知
;; れない）ので、このあたりの動向も注意しつつ（たまご ５版（たまごごは
;; ん）をやるとか言い出してるし(^_^;）、MIME での言語の取り扱いについ
;; て私なりの考えをまとめたいと思っております。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━



From keiichi ＠ nanap.org  Thu Jan 20 16:18:29 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 20 Jan 2000 16:18:29 +0900
Subject: line-move-ignore-invisible
In-Reply-To: <htxwvp5p9n0.fsf@mulelab3.etl.go.jp> (tomo@etl.go.jp's message of "20 Jan 2000 14:58:11 +0900")
References: <14462.53007.826000.133493@manakagawa-nt.osa.dec.com>
 <87vh4xw1ol.fsf@nakaji.tutrp.tut.ac.jp> <yosuvh4xaysz.fsf@jpl.org>
 <14462.54514.102000.504691@manakagawa-nt.osa.dec.com>
 <yosuiu0xaxl2.fsf@jpl.org> <fzwvp68fst.wl@gohome.org>
 <htxembfekqs.fsf@mulelab3.etl.go.jp> <upuuxmunm.fsf@kei.nanap.org>
 <htxwvp5p9n0.fsf@mulelab3.etl.go.jp>
Message-ID: <u1z7dqkhm.fsf@kei.nanap.org>

>>>>> 20 Jan 2000 14:58:11 +0900 に、
>>>>> Message-Id: <htxwvp5p9n0.fsf ＠ mulelab3.etl.go.jp> のメイルで、
>>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

圭一> ;; 無理がたたって、一日寝ていました。 ;_;
守岡> ;; お大事に。(って、もう回復されているのかな）

;; きっと1ヶ月は(本業面で ;-))ボーッとしていないと、直らないでしょう。 
;; ^^;;;;

圭一> >>>>> emacs-mime-ja の No. 00339
圭一> >>>>> Message-Id: <htxembfekqs.fsf ＠ mulelab3.etl.go.jp> で、
圭一> >>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

圭一> SEMI 1.13 では nana7 の今後の方針を決定できませんので、「必要な
圭一> 改良」の中に mime-entity-\(.*-\)?buffer の件も含まれているのであ
圭一> れば、この方針でお願いしたいと思います。

守岡> とりあえず、SEMI 1.14 ではこれらを使わないという仕様にし、順次、書き換
守岡> えを行うということで良いでしょうか？

はい、それで構いません。

圭一> ;; MIME-Edit next generation の方は、どうなるにせよガラッと\(変
圭一> ;; えなければならない\|たい\)と思いますので、ゆっくり待ちます。

守岡> ;; 待てないという声が出なければ、予定通り、MIME-Edit next
守岡> ;; generation に移行後、REMI 1.14 を SEMI 1.l4 (or 1.90) にする
守岡> ;; という方向で行こうと思います。mime-view 関連が落ち着いたら一
守岡> ;; 度 REMI 1.14.0 を release する予定です。

圭一> ;; 1.90 に一票。 :-)

守岡> ;; じゃあ、その時はそういうことで。

守岡> ;; なんとなく、mmediting.el をえいやっと書いてしまいたい機運も高まって
守岡> ;; はいるので、表示関係よりも先にこっちが出来てしまう可能性もあります
守岡> ;; が。(^_^;

;; こんなことを言っているようであれば、すぐでしょうから、 1.14 はやめて
;; しまって、いきなり 1.90 っていうのでも、問題ないかも知れませんね。 ;-)

やはり先ほどのメイルにも書いた通り、 API 変更は最小限にして、 1.x 最後の
バージョンとして、仏典結集バージョンにするというのも、なかなかよろしいの
ではないかという気がしてきました。

;; ここで、大きく API を変更しても、 1.90 or 2.00 がリリースされれば、ま
;; た、アプリケーションの方を変更することになると思いますし、一旦「安定
;; 版」的なバージョンを作るのも良いのではないかと。

SEMI については、最近の動向をあまり把握しておらず、何とも言えませんので、
ほかの方のご意見をうかがいたいと思います。

圭一> ;; ところで、 Emacs 21 に含めるという FLIM / SEMI はどのバージョ
圭一> ;; ンにするのでしょうか?

守岡> ;; 個人的には SEMI 2.0 にしたいのですが。

;; ぜひ。 :-)

守岡> とりあえず、FLIM 1.14 実装では mime-entity-\(.*-\)?buffer を obsolete
守岡> 宣言するという方向ではいかがでしょうか？

これで十分ですが、「仏典結集版」という位置づけにするのであれば、これすら
要らないように思います。

;; 実用上は、先日の SEMI への変更によって、現在のバージョンでも特に困っ
;; てはいませんし、今急いでやっていただいても、要望を出した私の方が、何
;; もできそうもありません。 ^^;;;

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From nakaji ＠ tutrp.tut.ac.jp  Mon Jan 24 11:18:45 2000
From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki)
Date: 24 Jan 2000 11:18:45 +0900
Subject: splitted mail error
Message-ID: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp>

中治です。

AL-Mail によって分割送信されたメールを合体させられません。

-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: Backtrace
型:         application/octet-stream
サイズ:     4542 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000124/ba497b2a/attachment.obj>
-------------- next part --------------
ちなみに、サマリバッファでは、順序が変わっています。
R  [   0:  From          ] Re: 学章 [1/7]
O  [   0:  From          ] Re: 学章 [2/7]
O  [   0:  From          ] Re: 学章 [3/7]
O  [   0:  From          ] Re: 学章 [4/7]
O  [   0:  From          ] Re: 学章 [6/7]
O  [   0:  From          ] Re: 学章 [5/7]
O  [   0:  From          ] Re: 学章 [7/7]
-- 
NAKAJI Hiroyuki (中治 弘行)

From keiichi ＠ nanap.org  Mon Jan 24 17:39:51 2000
From: keiichi ＠ nanap.org (Keiichi Suzuki)
Date: 24 Jan 2000 17:39:51 +0900
Subject: splitted mail error
In-Reply-To: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp> (NAKAJI Hiroyuki's message of "24 Jan 2000 11:18:45 +0900")
References: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp>
Message-ID: <uiu0jc17s.fsf@kei.nanap.org>

>>>>> semi-gnus-ja の No. 4875
>>>>> Message-Id: <8766wkb4ai.fsf ＠ nakaji.tutrp.tut.ac.jp> で、
>>>>> "中治" == NAKAJI Hiroyuki <nakaji ＠ tutrp.tut.ac.jp>さま曰く...

中治> AL-Mail によって分割送信されたメールを合体させられません。

AL-Mail でなければ、可能なのでしょうか?

Signaling: (error "invalid byte code")
  write-region-as-binary(1299 50815 "/home/nakaji/tmp/m-prts-nakaji/199907070752.AA00242 ＠ fukai.office.tut.ac.jp/1")

ということですので、 APEL をインストールし直せば、良いのではないかと思う
のですが...

-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B



From shuhei ＠ aqua.ocn.ne.jp  Mon Jan 24 18:30:22 2000
From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI)
Date: 24 Jan 2000 18:30:22 +0900
Subject: splitted mail error
References: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp>
 <uiu0jc17s.fsf@kei.nanap.org>
Message-ID: <86iu0jyfyp.fsf@aqua.ocn.ne.jp>

>>>>> In <uiu0jc17s.fsf ＠ kei.nanap.org>,
>>>>> Keiichi Suzuki <keiichi ＠ nanap.org> wrote:
> Signaling: (error "invalid byte code")
>   write-region-as-binary(1299 50815 "/home/nakaji/tmp/m-prts-nakaji/199907070752.AA00242 ＠ fukai.office.tut.ac.jp/1")
> 
> ということですので、 APEL をインストールし直せば、良いのではないか
> と思うのですが...

emacs の起動中に APEL を update して install したのではないでしょうか?
これは pces-20.el の ;;; -*-byte-compile-dynamic: t;-*- が原因ではない
かと思います.

;; SKK では write-region-as-binary を辞書の save 時に使用するので,
;; この error が出ると辞書が save できず, emacs が終了できない(;_;)
;; ということが以前は時々ありました. apel-shubit ではこれが再現しなく
;; なったので, byte-compile-dynamic が原因ではないかと思ったわけです.

-- 
Shuhei KOBAYASHI



From nakaji ＠ tutrp.tut.ac.jp  Mon Jan 24 19:37:37 2000
From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki)
Date: 24 Jan 2000 19:37:37 +0900
Subject: splitted mail error
In-Reply-To: <86iu0jyfyp.fsf@aqua.ocn.ne.jp>
 (Shuhei KOBAYASHI's message of "24 Jan 2000 18:30:22 +0900")
References: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp> <uiu0jc17s.fsf@kei.nanap.org> <86iu0jyfyp.fsf@aqua.ocn.ne.jp>
Message-ID: <87iu0j92mm.fsf@nakaji.tutrp.tut.ac.jp>

>>>>> In [semi-gnus-ja : No.4877] 
>>>>>	Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:

SK> > ということですので、 APEL をインストールし直せば、良いのではないか
SK> > と思うのですが...

SK> emacs の起動中に APEL を update して install したのではないでしょうか?

当たりです。毎晩 cron で cvs update; make install しているのですが、週
末は emacs を起動したままでした。

無事、読むことができました。どうもありがとうございます。
-- 
NAKAJI Hiroyuki (中治 弘行)



From minakaji ＠ osaka.email.ne.jp  Mon Jan 24 21:49:59 2000
From: minakaji ＠ osaka.email.ne.jp (Mikio Nakajima)
Date: Mon, 24 Jan 2000 21:49:59 +0900
Subject: splitted mail error
In-Reply-To: In your message of "24 Jan 2000 18:30:22 +0900"
	<86iu0jyfyp.fsf@aqua.ocn.ne.jp>
References: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp>
	<uiu0jc17s.fsf@kei.nanap.org>
	<86iu0jyfyp.fsf@aqua.ocn.ne.jp>
Message-ID: <sa6ogab63d4.wl@osaka.email.ne.jp>

At 24 Jan 2000 18:30:22 +0900,
Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:
 
> ;; SKK では write-region-as-binary を辞書の save 時に使用するので,
> ;; この error が出ると辞書が save できず, emacs が終了できない(;_;)
> ;; ということが以前は時々ありました. 

write-region-as-binary なんて使ってないも〜ん ;-p

-- 
中島幹夫 <minakaji ＠ osaka.email.ne.jp>
　　　　 <minakaji ＠ pdx.ne.jp> (急ぎのときはこちらへ)
http://www.asahi-net.or.jp/~gy2m-nkjm/



From shuhei ＠ aqua.ocn.ne.jp  Mon Jan 24 22:35:32 2000
From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI)
Date: 24 Jan 2000 22:35:32 +0900
Subject: byte-compile-dynamic is harmful ? (Re: splitted mail error)
References: <8766wkb4ai.fsf@nakaji.tutrp.tut.ac.jp>
 <uiu0jc17s.fsf@kei.nanap.org> <86iu0jyfyp.fsf@aqua.ocn.ne.jp>
 <sa6ogab63d4.wl@osaka.email.ne.jp>
Message-ID: <86zotvwq1n.fsf_-_@aqua.ocn.ne.jp>

>>>>> In <sa6ogab63d4.wl ＠ osaka.email.ne.jp>,
>>>>> Mikio Nakajima <minakaji ＠ osaka.email.ne.jp> wrote:
> > ;; SKK では write-region-as-binary を辞書の save 時に使用するので,
> > ;; この error が出ると辞書が save できず, emacs が終了できない(;_;)
> > ;; ということが以前は時々ありました. 
> write-region-as-binary なんて使ってないも〜ん ;-p

おおっと, 間違えた.
SKK で使っているのは write-region-as-coding-system の方ですね.
どちらも pces-20.el で定義されているので同じ問題が出るのですが.

-- 
Shuhei KOBAYASHI



From sanewo ＠ ba2.so-net.ne.jp  Tue Jan 25 00:17:59 2000
From: sanewo ＠ ba2.so-net.ne.jp (SANETO Takanori)
Date: Tue, 25 Jan 2000 00:17:59 +0900
Subject: another patch for semi-gnus
Message-ID: <200001241518.AAA17498@mail.ba2.so-net.ne.jp>

gnusのバージョンが上がったときなど、gnus-update-format が呼ばれると、
せっかく gnus-xmas-redefine した関数(gnus-tilde-pad-form)が gnus-spec 
の定義に戻ってしまい、modeline の表示が乱れてしまいます。

以下のパッチ(v.s. t-gnus-6.14.1-03)のようにするといいと思います。

-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: semi-gnus_patch2
型:         application/octet-stream
サイズ:     517 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000125/ab9c16a7/attachment.obj>
-------------- next part --------------
-- 
さねを <URL:mailto:sanewo ＠ ba2.so-net.ne.jp>

From sanewo ＠ ba2.so-net.ne.jp  Tue Jan 25 00:18:19 2000
From: sanewo ＠ ba2.so-net.ne.jp (SANETO Takanori)
Date: Tue, 25 Jan 2000 00:18:19 +0900
Subject: message() related patch for semi-gnus 
In-Reply-To: sanewo's message of Mon, 24 Jan 2000 23:59:00 +0900.
Message-ID: <200001241518.AAA17543@mail.ba2.so-net.ne.jp>

ML あてにすべきところ、参考にしたメールにCCで交ざっていたアドレスの方
に送ってしまっていました。済みません。

>semi-gnus というよりは、大部分はオリジナルの gnus の問題のような気もし
>ますが、message() の使い方に問題がある個所があるようです。
>
>message() の第一引数は format string なのですが、ここに 一般の文字列が
>渡されているところがあります。たまたま文字列に % が含まれていると、場
>合によってはエラーになったりすると思われます。
>
>以下、t-gnus-6.14.1-03 に対するパッチです:

-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: semi-gnus_patch
型:         application/octet-stream
サイズ:     9256 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20000125/1d5f1b6b/attachment.obj>
-------------- next part --------------
-- 
さねを <URL:mailto:sanewo ＠ ba2.so-net.ne.jp>

From sanewo ＠ ba2.so-net.ne.jp  Tue Jan 25 00:22:25 2000
From: sanewo ＠ ba2.so-net.ne.jp (SANETO Takanori)
Date: Tue, 25 Jan 2000 00:22:25 +0900
Subject: another patch for semi-gnus 
In-Reply-To: sanewo's message of Tue, 25 Jan 2000 00:17:59 +0900.
             <200001241518.AAA17498@mail.ba2.so-net.ne.jp>
Message-ID: <200001241522.AAA19013@mail.ba2.so-net.ne.jp>

うう、勘違いの二乗でした…

In article <200001241518.AAA17498 ＠ mail.ba2.so-net.ne.jp>
	SANETO Takanori <sanewo ＠ ba2.so-net.ne.jp> said:
>gnusのバージョンが上がったときなど、gnus-update-format が呼ばれると、
>せっかく gnus-xmas-redefine した関数(gnus-tilde-pad-form)が gnus-spec 
>の定義に戻ってしまい、modeline の表示が乱れてしまいます。
>
>以下のパッチ(v.s. t-gnus-6.14.1-03)のようにするといいと思います。

失礼しました。
-- 
さねを <URL:mailto:sanewo ＠ ba2.so-net.ne.jp>



From zero ＠ geocities.co.jp  Thu Jan 27 08:58:31 2000
From: zero ＠ geocities.co.jp (ZERO)
Date: Thu, 27 Jan 2000 08:58:31 +0900
Subject: 無題
Message-ID: <200001262358.IAA27815@postman.jah.ne.jp>




From t90553 ＠ mail.ecc.u-tokyo.ac.jp  Mon Jan 31 16:32:08 2000
From: t90553 ＠ mail.ecc.u-tokyo.ac.jp (Yoshiki Hayashi)
Date: 31 Jan 2000 16:32:08 +0900
Subject: EMY 1.13.1
Message-ID: <874sbuy9vr.fsf@dp50.ecc.u-tokyo.ac.jp>

Content-Disposition が inline の部分も attachment として解釈
する bug があったので、修正して version を上げました。
# test 用 folder にはそういう message を置いていたので、単純
# に bug の存在を忘れて release したらしい。(^^;;

文書に腐った MUA 対策を少し追加しました。文面を変更しようと
思ったのですが、commit してしまったのでまた今度にします。

ftp://www.sodan.org/pub/elisp/semi/emy-1.13.1.tar.gz

に置きました。
# 何故 host 名が www なのか、というつっこみは却下。:-P

-- 
Yoshiki Hayashi