From nakaji ＠ tutrp.tut.ac.jp Fri Dec 1 14:38:57 2000 From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 01 Dec 2000 14:38:57 +0900 Subject: semi-1_14 fails with mule@19.34 Message-ID: <86wvdkog3y.fsf@xa12.heimat.gr.jp> 中治＠豊橋です。 flim-1_14, semi-1_14 に update して、mule-2.3 ＠ 19.34 でインストールでき るか試してみました。FreeBSD の ports/japanese/mule-wnn6 でインストール した mule です。 結果、できませんでした。 例えば、flimは、いつ頃からか、 /usr/local/share/mule/site-lisp/flim 19.34/site-lisp/flim の2ヶ所にインストールされるようになっている(*)のですが、SEMI-CFG の (add-path "flim") によって、後者のみがload-pathに追加され(*)、そこには、mailcap.el しか ないので、 (or (module-installed-p 'mime) (error "Please install FLIM 1.6.0 or later.")) このエラーに当たるようです。 (*) そういう仕様ですか? apel, flim, semi の順にインストールしようとしたときのログを付けます。 -- NAKAJI Hiroyuki (中治 弘行) -------------- next part -------------- for d in apel flim semi; do \ ( cd $d; gmake install EMACS=/usr/local/bin/mule ) \ done /home/nakaji/elisp/apel gmake[1]: ???????? ???????????? `/home/nakaji/elisp/apel' /usr/local/bin/mule -batch -q -no-site-file -l APEL-MK -f compile-apel \ NONE NONE NONE LOADING /home/nakaji/elisp/apel/APEL-CFG... LOADING /home/nakaji/elisp/apel/APEL-ELS... LOADING /home/nakaji/elisp/apel/EMU-ELS... Wrote /home/nakaji/elisp/apel/broken.elc Wrote /home/nakaji/elisp/apel/product.elc Wrote /home/nakaji/elisp/apel/apel-ver.elc Wrote /home/nakaji/elisp/apel/pym.elc While compiling toplevel forms in file /home/nakaji/elisp/apel/poe.el: ** char-after called with 0 args, but requires 1 Wrote /home/nakaji/elisp/apel/poe.elc Wrote /home/nakaji/elisp/apel/pcustom.elc BROKEN FACILITY DETECTED: Emacs forgets executing CCL_EOF_BLOCK with encoding on empty input. BROKEN FACILITY DETECTED: Emacs forgets executing CCL_EOF_BLOCK with encoding on non-empty input. BROKEN FACILITY DETECTED: Emacs forgets executing CCL_EOF_BLOCK with decoding on empty input. BROKEN FACILITY DETECTED: Emacs forgets executing CCL_EOF_BLOCK with decoding on non-empty input. BROKEN FACILITY DETECTED: Emacs CCL read command does not accept more than 2 arguments. Wrote /home/nakaji/elisp/apel/pccl-om.elc Wrote /home/nakaji/elisp/apel/pccl.elc While compiling the end of the data in file /home/nakaji/elisp/apel/pces-om.el: ** The following functions are not known to be defined: insert-file-contents-as-coding-system, write-region-as-coding-system, find-file-noselect-as-coding-system Wrote /home/nakaji/elisp/apel/pces-om.elc Wrote /home/nakaji/elisp/apel/pces.elc Wrote /home/nakaji/elisp/apel/poem-om.elc While compiling the end of the data in file /home/nakaji/elisp/apel/poem.el: ** The following functions are not known to be defined: char-charset, split-char Wrote /home/nakaji/elisp/apel/poem.elc While compiling mime-charset-to-coding-system in file /home/nakaji/elisp/apel/mcs-om.el: ** defsubst mime-charset-to-coding-system was used before it was defined While compiling the end of the data: ** the function charsets-to-mime-charset is not known to be defined. Wrote /home/nakaji/elisp/apel/mcs-om.elc While compiling charsets-to-mime-charset in file /home/nakaji/elisp/apel/mcharset.el: ** reference to free variable charsets-mime-charset-alist While compiling find-mime-charset-by-charsets: ** reference to free variable default-mime-charset-detect-method-for-write ** reference to free variable default-mime-charset-for-write Wrote /home/nakaji/elisp/apel/mcharset.elc Wrote /home/nakaji/elisp/apel/timezone.elc Wrote /home/nakaji/elisp/apel/inv-19.elc Wrote /home/nakaji/elisp/apel/invisible.elc Wrote /home/nakaji/elisp/apel/emu-mule.elc While compiling the end of the data in file /home/nakaji/elisp/apel/emu.el: ** The following functions are not known to be defined: char-category-list, category-set-mnemonics, char-category-set, convert-string-kanji-code, convert-region-kanji-code Wrote /home/nakaji/elisp/apel/emu.elc Wrote /home/nakaji/elisp/apel/richtext.elc Wrote /home/nakaji/elisp/apel/mule-caesar.elc Wrote /home/nakaji/elisp/apel/alist.elc Wrote /home/nakaji/elisp/apel/calist.elc Wrote /home/nakaji/elisp/apel/path-util.elc Wrote /home/nakaji/elisp/apel/filename.elc Wrote /home/nakaji/elisp/apel/install.elc LISPDIR=/usr/local/share/mule/site-lisp VERSION_SPECIFIC_LISPDIR=/usr/local/share/mule/19.34/site-lisp /usr/local/bin/mule -batch -q -no-site-file -l APEL-MK -f install-apel \ NONE NONE NONE # gmake LOADING /home/nakaji/elisp/apel/APEL-CFG... LOADING /home/nakaji/elisp/apel/APEL-ELS... LOADING /home/nakaji/elisp/apel/EMU-ELS... LISPDIR=/usr/local/share/mule/site-lisp VERSION_SPECIFIC_LISPDIR=/usr/local/share/mule/19.34/site-lisp w -- EMACS=/usr/local/bin/mule static.el -> /usr/local/share/mule/19.34/site-lisp static.elc -> /usr/local/share/mule/19.34/site-lisp broken.el -> /usr/local/share/mule/19.34/site-lisp broken.elc -> /usr/local/share/mule/19.34/site-lisp product.el -> /usr/local/share/mule/19.34/site-lisp product.elc -> /usr/local/share/mule/19.34/site-lisp apel-ver.el -> /usr/local/share/mule/19.34/site-lisp apel-ver.elc -> /usr/local/share/mule/19.34/site-lisp pym.el -> /usr/local/share/mule/19.34/site-lisp pym.elc -> /usr/local/share/mule/19.34/site-lisp poe.el -> /usr/local/share/mule/19.34/site-lisp poe.elc -> /usr/local/share/mule/19.34/site-lisp pcustom.el -> /usr/local/share/mule/19.34/site-lisp pcustom.elc -> /usr/local/share/mule/19.34/site-lisp pccl-om.el -> /usr/local/share/mule/19.34/site-lisp pccl-om.elc -> /usr/local/share/mule/19.34/site-lisp pccl.el -> /usr/local/share/mule/19.34/site-lisp pccl.elc -> /usr/local/share/mule/19.34/site-lisp pces-om.el -> /usr/local/share/mule/19.34/site-lisp pces-om.elc -> /usr/local/share/mule/19.34/site-lisp pces.el -> /usr/local/share/mule/19.34/site-lisp pces.elc -> /usr/local/share/mule/19.34/site-lisp poem-om.el -> /usr/local/share/mule/19.34/site-lisp poem-om.elc -> /usr/local/share/mule/19.34/site-lisp poem.el -> /usr/local/share/mule/19.34/site-lisp poem.elc -> /usr/local/share/mule/19.34/site-lisp mcs-om.el -> /usr/local/share/mule/19.34/site-lisp mcs-om.elc -> /usr/local/share/mule/19.34/site-lisp mcharset.el -> /usr/local/share/mule/19.34/site-lisp mcharset.elc -> /usr/local/share/mule/19.34/site-lisp timezone.el -> /usr/local/share/mule/19.34/site-lisp timezone.elc -> /usr/local/share/mule/19.34/site-lisp inv-19.el -> /usr/local/share/mule/19.34/site-lisp inv-19.elc -> /usr/local/share/mule/19.34/site-lisp invisible.el -> /usr/local/share/mule/19.34/site-lisp invisible.elc -> /usr/local/share/mule/19.34/site-lisp emu-mule.el -> /usr/local/share/mule/19.34/site-lisp emu-mule.elc -> /usr/local/share/mule/19.34/site-lisp emu.el -> /usr/local/share/mule/19.34/site-lisp emu.elc -> /usr/local/share/mule/19.34/site-lisp richtext.el -> /usr/local/share/mule/19.34/site-lisp richtext.elc -> /usr/local/share/mule/19.34/site-lisp mule-caesar.el -> /usr/local/share/mule/19.34/site-lisp mule-caesar.elc -> /usr/local/share/mule/19.34/site-lisp alist.el -> /usr/local/share/mule/site-lisp/apel alist.elc -> /usr/local/share/mule/site-lisp/apel calist.el -> /usr/local/share/mule/site-lisp/apel calist.elc -> /usr/local/share/mule/site-lisp/apel path-util.el -> /usr/local/share/mule/site-lisp/apel path-util.elc -> /usr/local/share/mule/site-lisp/apel filename.el -> /usr/local/share/mule/site-lisp/apel filename.elc -> /usr/local/share/mule/site-lisp/apel install.el -> /usr/local/share/mule/site-lisp/apel install.elc -> /usr/local/share/mule/site-lisp/apel gmake[1]: ?????? ???????????? `/home/nakaji/elisp/apel' /home/nakaji/elisp/flim gmake[1]: ???????? ???????????? `/home/nakaji/elisp/flim' /usr/local/bin/mule -batch -q -no-site-file -l FLIM-MK -f compile-flim NONE NONE \ NONE LOADING /home/nakaji/elisp/flim/FLIM-CFG... LOADING /home/nakaji/elisp/flim/FLIM-ELS... While compiling the end of the data in file /home/nakaji/elisp/flim/mailcap.el: ** the function define-obsolete-variable-alias is not known to be defined. Wrote /home/nakaji/elisp/flim/mailcap.elc Wrote /home/nakaji/elisp/flim/mel-b-ccl.elc Wrote /home/nakaji/elisp/flim/mel-q-ccl.elc While compiling base64-external-encode-region in file /home/nakaji/elisp/flim/mel-b-el.el: ** reference to free variable base64-external-encoder While compiling base64-external-decode-region: ** reference to free variable base64-external-decoder While compiling base64-external-decode-string: ** reference to free variable base64-external-decoder While compiling toplevel forms: ** reference to free variable base64-internal-encoding-limit ** reference to free variable base64-internal-decoding-limit ** reference to free variable base64-internal-encoding-limit ** reference to free variable base64-external-encoder While compiling base64-write-decoded-region: ** reference to free variable base64-internal-decoding-limit ** reference to free variable base64-external-decoder ** reference to free variable base64-external-decoder-option-to-specify-file While compiling the end of the data: ** The following functions are not known to be defined: base64-encode-string, base64-decode-string Wrote /home/nakaji/elisp/flim/mel-b-el.elc Wrote /home/nakaji/elisp/flim/hex-util.elc Wrote /home/nakaji/elisp/flim/hmac-def.elc Wrote /home/nakaji/elisp/flim/md5.elc Wrote /home/nakaji/elisp/flim/md5-el.elc Wrote /home/nakaji/elisp/flim/md5-dl.elc Wrote /home/nakaji/elisp/flim/sha1.elc Wrote /home/nakaji/elisp/flim/sha1-el.elc Wrote /home/nakaji/elisp/flim/sha1-dl.elc While compiling toplevel forms in file /home/nakaji/elisp/flim/hmac-md5.el: ** md5 called with 4 arguments, but accepts only 1-3 ** md5 called with 4 arguments, but accepts only 1-3 ** the function md5-binary is not known to be defined. Wrote /home/nakaji/elisp/flim/hmac-md5.elc Wrote /home/nakaji/elisp/flim/hmac-sha1.elc While compiling std11-lexical-analyze in file /home/nakaji/elisp/flim/std11.el: ** reference to free variable std11-lexical-analyzer Wrote /home/nakaji/elisp/flim/std11.elc Wrote /home/nakaji/elisp/flim/luna.elc Wrote /home/nakaji/elisp/flim/mime-def.elc While compiling mime-encoding-list in file /home/nakaji/elisp/flim/mel.el: ** reference to free variable mime-encoding-list While compiling the end of the data: ** The following functions are not known to be defined: base64-encode-string, base64-decode-string Wrote /home/nakaji/elisp/flim/mel.elc Wrote /home/nakaji/elisp/flim/mel-q.elc Wrote /home/nakaji/elisp/flim/mel-u.elc Wrote /home/nakaji/elisp/flim/mel-g.elc While compiling eword-decode-and-fold-structured-field-body in file /home/nakaji/elisp/flim/eword-decode.el: ** reference to free variable eword-max-size-to-decode While compiling eword-lexical-analyze-internal: ** reference to free variable eword-lexical-analyzer Wrote /home/nakaji/elisp/flim/eword-decode.elc While compiling eword-encode-string in file /home/nakaji/elisp/flim/eword-encode.el: ** reference to free variable eword-encode-default-start-column While compiling eword-encode-address-list: ** reference to free variable eword-encode-default-start-column While compiling eword-encode-structured-field-body: ** reference to free variable eword-encode-default-start-column While compiling eword-encode-unstructured-field-body: ** reference to free variable eword-encode-default-start-column While compiling eword-find-field-encoding-method: ** reference to free variable eword-field-encoding-method-alist Wrote /home/nakaji/elisp/flim/eword-encode.elc Wrote /home/nakaji/elisp/flim/mime.elc While compiling mime-parse-Content-Transfer-Encoding in file /home/nakaji/elisp/flim/mime-parse.el: ** reference to free variable mime-lexical-analyzer While compiling mime-parse-message: ** reference to free variable :buffer ** reference to free variable :header-start ** reference to free variable :header-end ** reference to free variable :body-start ** reference to free variable :body-end Wrote /home/nakaji/elisp/flim/mime-parse.elc Wrote /home/nakaji/elisp/flim/mmgeneric.elc Wrote /home/nakaji/elisp/flim/mmbuffer.elc Wrote /home/nakaji/elisp/flim/mmcooked.elc While compiling the end of the data in file /home/nakaji/elisp/flim/mmdbuffer.el: ** the function mime-entity-body-buffer is not known to be defined. Wrote /home/nakaji/elisp/flim/mmdbuffer.elc Wrote /home/nakaji/elisp/flim/mmexternal.elc Wrote /home/nakaji/elisp/flim/mime-conf.elc Wrote /home/nakaji/elisp/flim/sasl.elc Wrote /home/nakaji/elisp/flim/sasl-cram.elc Wrote /home/nakaji/elisp/flim/sasl-digest.elc While compiling smtp-make-fqdn in file /home/nakaji/elisp/flim/smtp.el: ** reference to free variable smtp-fqdn ** reference to free variable smtp-local-domain While compiling smtp-send-buffer: ** reference to free variable smtp-server ** reference to free variable smtp-use-starttls ** reference to free variable smtp-service While compiling smtp-submit-package: ** reference to free variable smtp-use-starttls ** reference to free variable smtp-use-sasl While compiling smtp-primitive-auth: ** reference to free variable smtp-sasl-mechanisms ** reference to free variable smtp-sasl-user-name ** reference to free variable smtp-sasl-properties While compiling smtp-primitive-mailfrom: ** reference to free variable smtp-use-size ** reference to free variable smtp-use-8bitmime While compiling the end of the data: ** The following functions are not known to be defined: base64-encode-string, base64-decode-string Wrote /home/nakaji/elisp/flim/smtp.elc While compiling qmtp-send-package in file /home/nakaji/elisp/flim/qmtp.el: ** reference to free variable qmtp-timeout While compiling qmtp-send-buffer: ** reference to free variable qmtp-service Wrote /home/nakaji/elisp/flim/qmtp.elc While compiling toplevel forms in file /home/nakaji/elisp/flim/smtpmail.el: ** reference to free variable smtpmail-queue-dir ** reference to free variable smtpmail-queue-mail ** smtp-via-smtp is an obsolete function; It's old API. ** reference to free variable smtpmail-queue-dir While compiling smtpmail-send-queued-mail: ** smtp-via-smtp is an obsolete function; It's old API. Wrote /home/nakaji/elisp/flim/smtpmail.elc PREFIX=/usr/local LISPDIR=/usr/local/share/mule/site-lisp /usr/local/bin/mule -batch -q -no-site-file -l FLIM-MK -f install-flim NONE NONE \ NONE LOADING /home/nakaji/elisp/flim/FLIM-CFG... LOADING /home/nakaji/elisp/flim/FLIM-ELS... PREFIX=/usr/local LISPDIR=/usr/local/share/mule/site-lisp mailcap.el -> /usr/local/share/mule/19.34/site-lisp/flim mailcap.elc -> /usr/local/share/mule/19.34/site-lisp/flim mel-b-ccl.el -> /usr/local/share/mule/site-lisp/flim mel-b-ccl.elc -> /usr/local/share/mule/site-lisp/flim mel-q-ccl.el -> /usr/local/share/mule/site-lisp/flim mel-q-ccl.elc -> /usr/local/share/mule/site-lisp/flim mel-b-el.el -> /usr/local/share/mule/site-lisp/flim mel-b-el.elc -> /usr/local/share/mule/site-lisp/flim hex-util.el -> /usr/local/share/mule/site-lisp/flim hex-util.elc -> /usr/local/share/mule/site-lisp/flim hmac-def.el -> /usr/local/share/mule/site-lisp/flim hmac-def.elc -> /usr/local/share/mule/site-lisp/flim md5.el -> /usr/local/share/mule/site-lisp/flim md5.elc -> /usr/local/share/mule/site-lisp/flim md5-el.el -> /usr/local/share/mule/site-lisp/flim md5-el.elc -> /usr/local/share/mule/site-lisp/flim md5-dl.el -> /usr/local/share/mule/site-lisp/flim md5-dl.elc -> /usr/local/share/mule/site-lisp/flim sha1.el -> /usr/local/share/mule/site-lisp/flim sha1.elc -> /usr/local/share/mule/site-lisp/flim sha1-el.el -> /usr/local/share/mule/site-lisp/flim sha1-el.elc -> /usr/local/share/mule/site-lisp/flim sha1-dl.el -> /usr/local/share/mule/site-lisp/flim sha1-dl.elc -> /usr/local/share/mule/site-lisp/flim hmac-md5.el -> /usr/local/share/mule/site-lisp/flim hmac-md5.elc -> /usr/local/share/mule/site-lisp/flim hmac-sha1.el -> /usr/local/share/mule/site-lisp/flim hmac-sha1.elc -> /usr/local/share/mule/site-lisp/flim std11.el -> /usr/local/share/mule/site-lisp/flim std11.elc -> /usr/local/share/mule/site-lisp/flim luna.el -> /usr/local/share/mule/site-lisp/flim luna.elc -> /usr/local/share/mule/site-lisp/flim mime-def.el -> /usr/local/share/mule/site-lisp/flim mime-def.elc -> /usr/local/share/mule/site-lisp/flim mel.el -> /usr/local/share/mule/site-lisp/flim mel.elc -> /usr/local/share/mule/site-lisp/flim mel-q.el -> /usr/local/share/mule/site-lisp/flim mel-q.elc -> /usr/local/share/mule/site-lisp/flim mel-u.el -> /usr/local/share/mule/site-lisp/flim mel-u.elc -> /usr/local/share/mule/site-lisp/flim mel-g.el -> /usr/local/share/mule/site-lisp/flim mel-g.elc -> /usr/local/share/mule/site-lisp/flim eword-decode.el -> /usr/local/share/mule/site-lisp/flim eword-decode.elc -> /usr/local/share/mule/site-lisp/flim eword-encode.el -> /usr/local/share/mule/site-lisp/flim eword-encode.elc -> /usr/local/share/mule/site-lisp/flim mime.el -> /usr/local/share/mule/site-lisp/flim mime.elc -> /usr/local/share/mule/site-lisp/flim mime-parse.el -> /usr/local/share/mule/site-lisp/flim mime-parse.elc -> /usr/local/share/mule/site-lisp/flim mmgeneric.el -> /usr/local/share/mule/site-lisp/flim mmgeneric.elc -> /usr/local/share/mule/site-lisp/flim mmbuffer.el -> /usr/local/share/mule/site-lisp/flim mmbuffer.elc -> /usr/local/share/mule/site-lisp/flim mmcooked.el -> /usr/local/share/mule/site-lisp/flim mmcooked.elc -> /usr/local/share/mule/site-lisp/flim mmdbuffer.el -> /usr/local/share/mule/site-lisp/flim mmdbuffer.elc -> /usr/local/share/mule/site-lisp/flim mmexternal.el -> /usr/local/share/mule/site-lisp/flim mmexternal.elc -> /usr/local/share/mule/site-lisp/flim mime-conf.el -> /usr/local/share/mule/site-lisp/flim mime-conf.elc -> /usr/local/share/mule/site-lisp/flim sasl.el -> /usr/local/share/mule/site-lisp/flim sasl.elc -> /usr/local/share/mule/site-lisp/flim sasl-cram.el -> /usr/local/share/mule/site-lisp/flim sasl-cram.elc -> /usr/local/share/mule/site-lisp/flim sasl-digest.el -> /usr/local/share/mule/site-lisp/flim sasl-digest.elc -> /usr/local/share/mule/site-lisp/flim smtp.el -> /usr/local/share/mule/site-lisp/flim smtp.elc -> /usr/local/share/mule/site-lisp/flim qmtp.el -> /usr/local/share/mule/site-lisp/flim qmtp.elc -> /usr/local/share/mule/site-lisp/flim smtpmail.el -> /usr/local/share/mule/site-lisp/flim smtpmail.elc -> /usr/local/share/mule/site-lisp/flim gmake[1]: ?????? ???????????? `/home/nakaji/elisp/flim' /home/nakaji/elisp/semi gmake[1]: ???????? ???????????? `/home/nakaji/elisp/semi' /usr/local/bin/mule -batch -q -no-site-file -l SEMI-MK -f compile-semi \ NONE NONE NONE LOADING /home/nakaji/elisp/semi/SEMI-CFG... Please install FLIM 1.6.0 or later. gmake[1]: *** [elc] ?????? 255 gmake[1]: ?????? ???????????? `/home/nakaji/elisp/semi' gmake: *** [semi-mule] ?????? 2 From yamaoka ＠ jpl.org Fri Dec 1 21:36:17 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 01 Dec 2000 21:36:17 +0900 Subject: semi-1_14 fails with mule@19.34 References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> Message-ID: ごめんなさい、他のことにかまけていて中治さんのメッセージを見落としてい ました。(^^;;) >>>>> In [emacs-mime-ja : No.00692] >>>>> NAKAJI Hiroyuki wrote: 中治さん> flim-1_14, semi-1_14 に update して、mule-2.3 ＠ 19.34 でインス 中治さん> トールできるか試してみました。FreeBSD の 中治さん> ports/japanese/mule-wnn6 でインストールした mule です。 中治さん> 結果、できませんでした。 中治さん> 例えば、flimは、いつ頃からか、 中治さん> /usr/local/share/mule/site-lisp/flim 中治さん> 19.34/site-lisp/flim 中治さん> の2ヶ所にインストールされるようになっている(*)のですが、 中治さん> SEMI-CFG の 中治さん> (add-path "flim") 中治さん> によって、後者のみがload-pathに追加され(*)、そこには、 中治さん> mailcap.el しかないので、 ぼくも T-gnus で同じ問題に遭遇したので、T-gnus では (add-path "flim") の後に対策を追加しました。 `t-gnus-6_14' では lpath.el、`t-gnus-6_14-quimby' では dgnushack.el で す。 まだ新しい FLIM 1.14 の元で SEMI を make したことがなかったので気が付 かなかったのですが (^^;;)、SEMI-CFG の場合だったらこんな感じでしょうか。 (add-path "flim") (if (not (module-installed-p 'mel)) ;; FLIM 1.14 may have installed in two "flim" subdirectories. (progn (setq load-path (cons (expand-file-name "flim" (file-name-directory (get-latest-path "^apel$" t))) load-path)) (if (not (module-installed-p 'mel)) (error "\nFLIM package does not found in %s.\n\n" load-path)))) "apel/" の横並びに "flim/" が存在する場合だけ有効です。`mel' を探して いるのは単に T-gnus を Mule 2.3 で make したときに最初に現れるエラーに 基づいています。 とは言うものの、可能なら FLIM の全モジュールは "flim" という単一のディ レクトリにインストールしてもらえる方がありがたいです。 ;; 阿呆なことを書いてあったら、修正 or ご指導をお願いします。 -- Katsumi Yamaoka From nakaji ＠ tutrp.tut.ac.jp Fri Dec 1 22:08:32 2000 From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 01 Dec 2000 22:08:32 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: (Katsumi Yamaoka's message of "01 Dec 2000 21:36:17 +0900") References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> Message-ID: <86wvdk5lwv.fsf@xa12.heimat.gr.jp> 中治です。 >>>>> In [emacs-mime-ja : No.00693] >>>>> Katsumi Yamaoka wrote: 山岡さん> ごめんなさい、他のことにかまけていて中治さんのメッセージを見 山岡さん> 落としていました。(^^;;) 見つけていただいて光栄です。:-) 中治> flim-1_14, semi-1_14 に update して、mule-2.3 ＠ 19.34 でインス 中治> トールできるか試してみました。FreeBSD の 中治> ports/japanese/mule-wnn6 でインストールした mule です。 中治> 結果、できませんでした。 山岡さん> まだ新しい FLIM 1.14 の元で SEMI を make したことがなかった 山岡さん> ので気が付かなかったのですが (^^;;)、SEMI-CFG の場合だったら 山岡さん> こんな感じでしょうか。 [snip] 山岡さん> とは言うものの、可能なら FLIM の全モジュールは "flim" という 山岡さん> 単一のディレクトリにインストールしてもらえる方がありがたいで 山岡さん> す。 僕もそのように思いますが、同時に、「どうして別ディレクトリに入るように なったの?」という疑問もあります。 -- NAKAJI Hiroyuki (中治 弘行) From yamaoka ＠ jpl.org Mon Dec 4 08:27:55 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Mon, 4 Dec 2000 08:27:55 +0900 Subject: semi-1_14 fails with mule@19.34 References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> Message-ID: <14890.55035.646737.279798@jpl.org> >>>>> In [emacs-mime-ja : No.00694] >>>>> NAKAJI Hiroyuki wrote: 山岡> とは言うものの、可能なら FLIM の全モジュールは "flim" という単一 山岡> のディレクトリにインストールしてもらえる方がありがたいです。 と書きましたが、古い Emacsen では mailcap.el(c) がインストールされてい る方の /usr/local/mule/19.34/site-lisp/flim/ は自動的に load-path に追 加されないので、それを望むならば例えば /usr/local/mule/19.34/site-lisp/subdirs.el で "flim/" を追加する必要があります。このファイルに (normal-top-level-add-to-load-path '( "/usr/local/share/mule/site-lisp/flim/" "flim/" )) と書いて、/usr/local/mule/site-lisp/subdirs.el では "flim/" を追加しな いようにする、と言うのはたいした手間ではないことに気がつきました。 SEMI-CFG や T-gnus の installer に変なものを入れるよりは、そういう対処 を推奨した方が良いのではないかと思いはじめています。 中治さん> 僕もそのように思いますが、同時に、「どうして別ディレクトリに 中治さん> 入るようになったの?」という疑問もあります。 FLIM に元からあった守岡さん作の mailcap.el と別に、W. M. Perry さん作 の mailcap.el が Gnus に含まれていることはご存知ですか? それらの目的 とするものはよく似ているのですが、インターフェース仕様が違うので互換性 がありません。Emacs 21.1 に後者の mailcap.el を含む Gnus 5.9 が標準で 付属することになったので、load-path の順序によっては mailcap.el を使う アプリが誤動作します。FLIM 1.14 の mailcap.el が version specific な方 のディレクトリにインストールされるようになったのは、普通に Emacs を起 動した場合にそちらの方が load-path の優先度が高い、言い換えれば FLIM をインストールする人は FLIM の mailcap.el を使う意志があるとみなされる、 のが理由だと思います。 なお T-gnus では、Gnus に mailcap.el が登場したときにすでに FLIM には mailcap.el が含まれていたので、市川さんが gnus-mailcap.el に改名して対 処しました。これは実は T-gnus では使われていません。 -- Katsumi Yamaoka From nakaji ＠ tutrp.tut.ac.jp Mon Dec 4 09:53:16 2000 From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 04 Dec 2000 09:53:16 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: <14890.55035.646737.279798@jpl.org> (Katsumi Yamaoka's message of "Mon, 4 Dec 2000 08:27:55 +0900") References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> Message-ID: <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> 中治です。 >>>>> In [emacs-mime-ja : No.00695] >>>>> Katsumi Yamaoka wrote: 中治> 僕もそのように思いますが、同時に、「どうして別ディレクトリに 中治> 入るようになったの?」という疑問もあります。 山岡さん> FLIM に元からあった守岡さん作の mailcap.el と別に、 山岡さん> W. M. Perry さん作の mailcap.el が Gnus に含まれていることは 山岡さん> ご存知ですか? あ、そう言えば、最近、話題に上がっていたような… …ぐらいにしか知りませんでした。 山岡さん> それらの目的とするものはよく似ているのですが、インターフェー [snip] 山岡さん> う意志があるとみなされる、のが理由だと思います。 そういうことだったんですね。 えっと、そうすると、話を元へ戻しますが、 (add-path "flim") で、/usr/local/share/mule/19.34/site-lisp/flim しか追加されないのは、 そういう仕様だからですか? SEMIのインストールに関して言えば、 /usr/local/share/mule/site-lisp/flim が追加されないとうれしくないので すが…。^^; -- NAKAJI Hiroyuki (中治 弘行) From yamaoka ＠ jpl.org Mon Dec 4 10:19:25 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 04 Dec 2000 10:19:25 +0900 Subject: semi-1_14 fails with mule@19.34 References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00696] >>>>> NAKAJI Hiroyuki wrote: 中治さん> えっと、そうすると、話を元へ戻しますが、 中治さん> (add-path "flim") 中治さん> で、/usr/local/share/mule/19.34/site-lisp/flim しか追加され 中治さん> ないのは、そういう仕様だからですか? SEMIのインストールに関し 中治さん> て言えば、/usr/local/share/mule/site-lisp/flim が追加されな 中治さん> いとうれしくないのですが…。^^; それもそうなんですが (^^;;)、そもそも (add-path "flim") というのは古い Emacsen が自動的に load-path を作ってくれないことへの対策なわけです。 それを最近の FLIM 1.14 にも適用するには、ぼくが T-gnus でやったような、 どちらかといえばあまり美しくない方法を採ることになります。 ;; あの方法は完璧ではありませんが、しかしかなり高い確率で成功します。 ぼく個人の意見としては、(add-path "flim") のようなお節介は今後はやめて、 その代わり古い Emacsen を使う場合における注意書きを追加するのが良いの ではないかと思います。 つまり、Mule 2.3 のようなものを使っている人はそれなりの理由があってそ うしているのでしょうが、今では主流から外れたものを使っていることを認識 し、それを使うために必要なことは自分でまかなうべき、という考えです。 利用者がやらなければいけないことは SEMI パッケージなどの改造ではありま せんし、それ (subdirs.el の作成と編集) を行なうことによって得られる利 益は大きいはずです。 -- Katsumi Yamaoka From nakaji ＠ tutrp.tut.ac.jp Mon Dec 4 10:33:53 2000 From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 04 Dec 2000 10:33:53 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: (Katsumi Yamaoka's message of "04 Dec 2000 10:19:25 +0900") References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: <87y9xx2cn2.fsf@nakaji.tutrp.tut.ac.jp> >>>>> In [emacs-mime-ja : No.00697] >>>>> Katsumi Yamaoka wrote: 中治> (add-path "flim") 中治> で、/usr/local/share/mule/19.34/site-lisp/flim しか追加され 中治> ないのは、そういう仕様だからですか? SEMIのインストールに関し 中治> て言えば、/usr/local/share/mule/site-lisp/flim が追加されな 中治> いとうれしくないのですが…。^^; 山岡さん> ぼく個人の意見としては、(add-path "flim") のようなお節介は今 山岡さん> 後はやめて、その代わり古い Emacsen を使う場合における注意書 山岡さん> きを追加するのが良いのではないかと思います。つまり、Mule 2.3 山岡さん> のようなものを使っている人はそれなりの理由があってそうしてい 山岡さん> るのでしょうが、今では主流から外れたものを使っていることを認 山岡さん> 識し、それを使うために必要なことは自分でまかなうべき、という 山岡さん> 考えです。 それは、たしかにそうですね。ただ、Mule-2.3のようなものを使っているのは、 いつごろから、主流じゃなくなったんでしょうか? 現在は、Emacs-20.7 + SKK が主流で、Emacs-20.7 + tamago or emcws が亜流? 将来は、Emacs-21.x + SKK or tamago が本流? ;; そういえば、21.1 のリリースに先立って、Emacs のソースの CVS による ;; 取得ができるようになるらしいです。 山岡さん> 利用者がやらなければいけないことは SEMI パッケージなどの改造 山岡さん> ではありませんし、それ (subdirs.el の作成と編集) を行なうこ 山岡さん> とによって得られる利益は大きいはずです。 では、「それ」を注意書に盛り込んでもらえることを切望します。^^; 僕が mule ＠ 19.34 で subdirs.el を使っていない理由の一つが、「それをどの ように書けば良いのか、どこに置いておけば良いのか、ということを知らない」 だからです。 -- NAKAJI Hiroyuki (中治 弘行) From yamaoka ＠ jpl.org Mon Dec 4 10:49:28 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 04 Dec 2000 10:49:28 +0900 Subject: semi-1_14 fails with mule@19.34 References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> <87y9xx2cn2.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00698] >>>>> NAKAJI Hiroyuki wrote: 山岡> ぼく個人の意見としては、(add-path "flim") のようなお節介は今後は 山岡> やめて、その代わり古い Emacsen を使う場合における注意書きを追加 山岡> するのが良いのではないかと思います。つまり、Mule 2.3 のようなも 山岡> のを使っている人はそれなりの理由があってそうしているのでしょうが、 山岡> 今では主流から外れたものを使っていることを認識し、それを使うため 山岡> に必要なことは自分でまかなうべき、という考えです。 中治さん> それは、たしかにそうですね。ただ、Mule-2.3のようなものを使っ 中治さん> ているのは、いつごろから、主流じゃなくなったんでしょうか? ごめんなさい、最初にお断わり申し上げたように、あれはぼく個人の意見です。 ですので、かなり へ理屈 入ってますが (^^;;) Mule 2.3 が主流ではなくなっ たのはぼくが Mule 2.3 を日常の文房具として使わなくなったときです。:-p 山岡さん> 利用者がやらなければいけないことは SEMI パッケージなどの改造 山岡さん> ではありませんし、それ (subdirs.el の作成と編集) を行なうこ 山岡さん> とによって得られる利益は大きいはずです。 中治さん> では、「それ」を注意書に盛り込んでもらえることを切望します。^^; じつは APEL の README に書いてあるんですが、 中治さん> 僕が mule ＠ 19.34 で subdirs.el を使っていない理由の一つが、 中治さん> 「それをどのように書けば良いのか、どこに置いておけば良いのか、 中治さん> ということを知らない」だからです。 あれだけだと何をどうしたらよいのかわからないかもしれませんね。もっと手 取り足取り形式で書く、他のパッケージにも入れる、ことは必要だと思います。 で、各組共通だったら、どこかの web サーバに置くのでも良いですね。 ところで、管さんに文句を言われる前に書いてしまいますが、Nemacs などの 場合は subdirs.el があっても意味がありません。今のところ CLIME 1.13 と SEMI 1.13 だったら問題無いのですが、とりあえずこの議論は 1.14 以上に絞 るべきかな。 -- Katsumi Yamaoka From Taiji.Can ＠ atesoft.advantest.co.jp Mon Dec 4 11:07:38 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Mon, 04 Dec 2000 11:07:38 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> <87y9xx2cn2.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: 菅です。 > 中治さん> それは、たしかにそうですね。ただ、Mule-2.3のようなものを使っ > 中治さん> ているのは、いつごろから、主流じゃなくなったんでしょうか? > > ごめんなさい、最初にお断わり申し上げたように、あれはぼく個人の意見です。 > ですので、かなり へ理屈 入ってますが (^^;;) Mule 2.3 が主流ではなくなっ > たのはぼくが Mule 2.3 を日常の文房具として使わなくなったときです。:-p まだ、mule でも重い。というので、nemacs から離れ無い人もいますし、 mule までは何とかたどり着いたけど、その上になるともっと遅いし、今、自分が 必要な機能は編集だから軽くて良い、という開発者は多いです。:-) > ところで、管さんに文句を言われる前に書いてしまいますが、Nemacs などの > 場合は subdirs.el があっても意味がありません。今のところ CLIME 1.13 と > SEMI 1.13 だったら問題無いのですが、とりあえずこの議論は 1.14 以上に絞 > るべきかな。 いや、知っています。:-) 1.14 以上の議論で良いと思います。 clime は 1.14 にはならないのではないかなぁ、と思っていますし。 ＃で、wl でのNemacs サーポートは 2.4.x までかなぁ。とか。:-) -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 4 12:01:11 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 04 Dec 2000 12:01:11 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: Taiji.Can@atesoft.advantest.co.jp's message of "Mon, 04 Dec 2000 11:07:38 +0900" References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> <87y9xx2cn2.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: >>>>> [emacs-mime-ja : No.00700] にて >>>>> “菅さん”= Taiji.Can ＠ atesoft.advantest.co.jp さま曰く: 菅さん> clime は 1.14 にはならないのではないかなぁ、と思っていますし。 前にもお話したような気もしますが（でも、既に約１年過ぎたような気もする ので、きっとお話してたとしてもお忘れだと思いますが(^_^;;;）、SEMI を Emacs 21 に入れるという話（正確には、SEMI を使って Emacs 21 の RMAIL を MIME 化するという計画）があり、この関連で、FLIM/SEMI 1.14 から poe/emu 関連の code をなるべく除去する必要があります。 SEMI に関しては概ね semi-def.el で吸収することが可能だと思われますし、 XEmacs との絡みもありますので、emacsen 間の互換性の問題に関して、現状 を大きく変えることはないと思います。 一方、FLIM に関しては main module が並立的であることと、新しい emacsen を仮定すればおそらく poe/poem なしに可搬性の高い code を書くのはそれほ ど困難ではないと考えられることから、できるだけ、poe/poem を除去する方 向で行きたいと思っています。 具体的には、おそらく character indexing の emacsen を仮定すると、それ が安定した GNU Emacs 20.4 および XEmacs 21.1 ないし 21.2 以降を仮定し たいと思います。なお、MEL の Emacs 21 で用いない module に関しては例外 として良いと思います。 このため、byte indexing や古い Mule API を持つ emacsen に対しては、 CLIME 1.14（clime-1_14 枝）を作り、こで対処して頂きたいと思います。 なお、mailcap.{el|elc} を版依存 load-path に install するようにした件 に関しては、 を御参照ください。obsolete な module の install に関しては、良い案を持っていないので、どなたか改良案とでき れば実装を行って頂けると助かります。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From nakaji ＠ tutrp.tut.ac.jp Mon Dec 4 12:12:34 2000 From: nakaji ＠ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 04 Dec 2000 12:12:34 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: (Katsumi Yamaoka's message of "04 Dec 2000 10:49:28 +0900") References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> <87y9xx2cn2.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: <87k89g3mn1.fsf@nakaji.tutrp.tut.ac.jp> 中治です。個人的には納得して解決しました。 >>>>> In [emacs-mime-ja : No.00699] >>>>> Katsumi Yamaoka wrote: 中治> では、「それ」を注意書に盛り込んでもらえることを切望します。^^; 山岡さん> じつは APEL の README に書いてあるんですが、 おぉ、ありますね。 ＝＝＝ここから＝＝＝ load-path（Emacs と MULE の場合） ================================ もし Emacs もしくは Mule をお使いなら、APEL を install した場所を load-path に追加してください。もし Emacs 19.29 以降または Emacs 20.1, 20.2 を使って初期設定でインストールしたのなら、次のように subdirs.el を書くことができます。 -------------------------------------------------------------------- (normal-top-level-add-to-load-path '("apel")) -------------------------------------------------------------------- もし Emacs 20.3 以降もしくは XEmacs を使って普通にインストールするの ならば、load-path を設定する必要はありません。 ＝＝＝ここまで＝＝＝ たしかに、他の情報に埋もれて、発見しにくいかも知れません。 中治> 僕が mule ＠ 19.34 で subdirs.el を使っていない理由の一つが、 中治> 「それをどのように書けば良いのか、どこに置いておけば良いのか、 中治> ということを知らない」だからです。 山岡さん> あれだけだと何をどうしたらよいのかわからないかもしれませんね。 山岡さん> もっと手取り足取り形式で書く、他のパッケージにも入れる、こと 山岡さん> は必要だと思います。で、各組共通だったら、どこかの web サー 山岡さん> バに置くのでも良いですね。 ここは一つ、jpl.org で。:-) さしあたり、 (normal-top-level-add-to-load-path '( "apel" "bbdb" "bitmap" "flim" "mu" "semi" "t-gnus" )) というのを作って、今回のトラブルを克服することができました。そして、こ のようなリストをつくる部分を自動化することを補助するための仕組みが Emacsには存在するに違いないという確信を持つところまで行けました。 ;; 調べていません。m(__)m 例えば、 #!/bin/bash cd /usr/local/share/mule/site-lisp echo "(normal-top-level-add-to-load-path" >subdirs.el echo " '(" >>subdirs.el for d in *; do test -d $d && echo " \"$d\"" >>subdirs.el done echo " ))" >>subdirs.el というシェルスクリプトの for ループを実現する elisp function (*)があれ ば、subdirs.el は (*) そのものズバリがなくても、そんなに難しくなく書けるはず? (normal-top-level-add-to-load-path (such-function)) と、簡単に書けるはずですよね。ディレクトリが増えたり、名前が変わっても、 これで安心。 -- NAKAJI Hiroyuki (中治 弘行) From Taiji.Can ＠ atesoft.advantest.co.jp Mon Dec 4 14:23:56 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Mon, 04 Dec 2000 14:23:56 +0900 Subject: semi-1_14 fails with mule@19.34 In-Reply-To: References: <86wvdkog3y.fsf@xa12.heimat.gr.jp> <86wvdk5lwv.fsf@xa12.heimat.gr.jp> <14890.55035.646737.279798@jpl.org> <874s0l3t37.fsf@nakaji.tutrp.tut.ac.jp> <87y9xx2cn2.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: 菅です。 > 菅さん> clime は 1.14 にはならないのではないかなぁ、と思っていますし。 > > 前にもお話したような気もしますが（でも、既に約１年過ぎたような気もする > ので、きっとお話してたとしてもお忘れだと思いますが(^_^;;;）、SEMI を 忘れていました。 X-Mail-Count: 00219 この辺りの話かな？と、思います。 > 一方、FLIM に関しては main module が並立的であることと、新しい emacsen > を仮定すればおそらく poe/poem なしに可搬性の高い code を書くのはそれほ > ど困難ではないと考えられることから、できるだけ、poe/poem を除去する方 > 向で行きたいと思っています。 > > 具体的には、おそらく character indexing の emacsen を仮定すると、それ > が安定した GNU Emacs 20.4 および XEmacs 21.1 ないし 21.2 以降を仮定し > たいと思います。なお、MEL の Emacs 21 で用いない module に関しては例外 > として良いと思います。 > > このため、byte indexing や古い Mule API を持つ emacsen に対しては、 > CLIME 1.14（clime-1_14 枝）を作り、こで対処して頂きたいと思います。 なるほど。 すると又しばらくはNemacs/Mule2.3 でも頑張れそうな気がしますね。:-) -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From ueno ＠ bug.org Mon Dec 4 20:12:51 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 04 Dec 2000 20:12:51 +0900 Subject: SEMI variants Message-ID: <87k89g4ez0.fsf@gg.bug.org> 上野です。 SEMI variants のページ (http://jasmiso.org/~tashiron/semi-variant.html) の記述が現状を反映していないように見えるので、折角なので、 OSD 風の DTD を作ってみました。;; すみません。RDF は良く知らないので。^_^;; http://www.unixuser.org/~ueno/tmp/semi-variants/ もし、このような形式で十分であれば、cvs.m17n.org に import し、 maintainer の皆様の責任でエントリを加えて頂くのが良いと思いますが、 如何でしょうか？ 当面は僕の把握している限りの情報を加え、個人的に利用しようと考えています。 -- Daiki Ueno From ueno ＠ bug.org Tue Dec 5 08:56:37 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 05 Dec 2000 08:56:37 +0900 Subject: SEMI variants In-Reply-To: <87k89g4ez0.fsf@gg.bug.org> References: <87k89g4ez0.fsf@gg.bug.org> Message-ID: <873dg3kafe.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00704] >>>>> Daiki Ueno wrote: > SEMI variants のページ (http://jasmiso.org/~tashiron/semi-variant.html) > の記述が現状を反映していないように見えるので、折角なので、 > OSD 風の DTD を作ってみました。;; すみません。RDF は良く知らないので。^_^;; > http://www.unixuser.org/~ueno/tmp/semi-variants/ > もし、このような形式で十分であれば、cvs.m17n.org に import し、 > maintainer の皆様の責任でエントリを加えて頂くのが良いと思いますが、 > 如何でしょうか？ とりあえず、module 名 semi-variants で import しました。 ;; www 以下に add したほうが良かったのかも知れませんが。 手動で HTML に変換したものを、以下の場所に置いておきます。 http://www.unixuser.org/~ueno/semi-variants/ 気が向きましたら、御自分の branch の情報も加えてやってください。 ;; PSGML がインストールされていれば、簡単に編集できると思います。 ;; 参考: http://db-www.aist-nara.ac.jp/xml/psgml/ では。 -- Daiki Ueno From watanabe ＠ sigmaitec.co.jp Tue Dec 5 18:29:37 2000 From: watanabe ＠ sigmaitec.co.jp (=?ISO-2022-JP?B?GyRCRU9KVRsoQiA=?= =?ISO-2022-JP?B?GyRCQDUbKEI=?= / Tadashi Watanabe) Date: 05 Dec 2000 18:29:37 +0900 Subject: xemacs-codename of XEmacs 21.2 (beta38) Message-ID: 渡辺と申します。 XEmacs 21.2 (beta38) の xemacs-codename の値は、 Value: "Peisino,Ak" なのですが、このメールのように、User-Agent: 内で、MIME エンコードされ ずに出て行ってしまいます。 -- 渡辺 正 / Tadashi Watanabe From yamaoka ＠ jpl.org Tue Dec 5 18:40:35 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 05 Dec 2000 18:40:35 +0900 Subject: xemacs-codename of XEmacs 21.2 (beta38) References: Message-ID: >>>>> In [emacs-mime-ja : No.00706] >>>>> watanabe ＠ sigmaitec.co.jp (渡辺 正 / Tadashi Watanabe) wrote: 渡辺さん> XEmacs 21.2 (beta38) の xemacs-codename の値は、 渡辺さん> Value: "Peisinoë" 渡辺さん> なのですが、このメールのように、User-Agent: 内で、MIME エン 渡辺さん> コードされずに出て行ってしまいます。 この件、さきほど xemacs-beta で言ったのですが、ぼくは .emacs の先頭に (if (and (featurep 'xemacs) (string-match "^21\\.2 (beta38)" emacs-version)) (setq emacs-version (decode-coding-string emacs-version 'iso-2022-jp) xemacs-codename (decode-coding-string xemacs-codename 'iso-2022-jp))) と書いて対処しました。もしかしたら version.sh を iso-8859-1 でセーブし てから make し直すと良さそうな気もしますが未確認。 -- Katsumi Yamaoka From watanabe ＠ sigmaitec.co.jp Tue Dec 5 19:29:43 2000 From: watanabe ＠ sigmaitec.co.jp (=?ISO-2022-JP?B?GyRCRU9KVRsoQiAbJEJANRsoQg==?= (Tadashi Watanabe)) Date: 05 Dec 2000 19:29:43 +0900 Subject: xemacs-codename of XEmacs 21.2 (beta38) In-Reply-To: (Katsumi Yamaoka's message of "05 Dec 2000 18:40:35 +0900") References: Message-ID: 渡辺です。 >>>>> [emacs-mime-ja : No.00707] にて >>>>> “山岡”= Katsumi Yamaoka さま曰く: 渡辺> XEmacs 21.2 (beta38) の xemacs-codename の値は、 渡辺> Value: "Peisinoë" 渡辺> なのですが、このメールのように、User-Agent: 内で、MIME エン 渡辺> コードされずに出て行ってしまいます。 山岡> もしかしたら version.sh を iso-8859-1 でセーブしてから make し直 山岡> すと良さそうな気もしますが未確認。 こちらを試したところ、 cd ./src && make all make[1]: Entering directory `/tmp/xemacs-21.2.38/src' ./temacs -nd -batch -l /tmp/xemacs-21.2.38/src/../lisp/update-elc.el Fatal error: assertion failed, file mule-charset.h, line 604, fb < 0xA0 となってしまいましたので、 山岡> この件、さきほど xemacs-beta で言ったのですが、ぼくは .emacs の先頭に 山岡> (if (and (featurep 'xemacs) 山岡> (string-match "^21\\.2 (beta38)" emacs-version)) 山岡> (setq emacs-version (decode-coding-string emacs-version 'iso-2022-jp) 山岡> xemacs-codename (decode-coding-string xemacs-codename 'iso-2022-jp))) 山岡> と書いて対処しました。 こちらを使わせていただきました。ありがとうございました。 -- 渡辺 正 / Tadashi Watanabe From ueno ＠ bug.org Wed Dec 6 21:30:55 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 06 Dec 2000 21:30:55 +0900 Subject: semi-1_14 In-Reply-To: References: Message-ID: <87elzln340.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00670] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: > semi-1_14 枝を作りました。 > 今の所、remi-1_14 枝の最終版の中身が入っています。 > commiter の皆様、今後は semi-1_13 枝、remi-1_14 枝に代わり、semi-1_14 > を公式開発枝として使ってください。 Emacs 20.4 以降を target とするのなら、折角なので、EMIKO で行っている ような、純粋な widget API の使用を含めては如何でしょうか。 widget.texi に記載されていない widget-convert-button を利用するのが 純粋なのか、と言われると返答に窮しますが ^_^;; 最近の Gnus でも MIME button の表示には widget-convert-button を介しているので、問題ないのでは ないかと思います。 ;; 現状の WEMI そのものを merge するというのには断固反対します。 週末までに反対意見がなければ実際に作業を行います。 -- Daiki Ueno From tomo ＠ m17n.org Thu Dec 7 10:27:51 2000 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 07 Dec 2000 10:27:51 +0900 Subject: semi-1_14 In-Reply-To: Daiki Ueno's message of "06 Dec 2000 21:30:55 +0900" References: <87elzln340.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00709] >>>>> "Daiki" = Daiki Ueno wrote: Daiki> > semi-1_14 枝を作りました。 Daiki> > 今の所、remi-1_14 枝の最終版の中身が入っています。 Daiki> > commiter の皆様、今後は semi-1_13 枝、remi-1_14 枝に代わり、 Daiki> > semi-1_14 を公式開発枝として使ってください。 Daiki> Emacs 20.4 以降を target とするのなら、折角なので、EMIKO で行っ Daiki> ているような、純粋な widget API の使用を含めては如何でしょうか。 Daiki> widget.texi に記載されていない widget-convert-button を利用する Daiki> のが純粋なのか、と言われると返答に窮しますが ^_^;; 最近の Gnus Daiki> でも MIME button の表示には widget-convert-button を介している Daiki> ので、問題ないのではないかと思います。 Daiki> ;; 現状の WEMI そのものを merge するというのには断固反対します。 私が WEMI を始めた時の目的は、見栄えを良くすることではなくて、ボタンな どの共通の抽象化の基盤として widget を使うようにしたいということだった ので、この方向には賛成します。 ;; ただ、SEMI 枝の widget 化は「米原」で行いたいという、version 名に基 ;; づくふざけた（でも、本人は結構真剣(^_^;;;）希望により、今 widget 化 ;; するのはちょっとだけ悲しかったりします。また、同様の理由で、現行の ;; emiko-1_14 が wemi-1_14 になったら良いなあという希望もありますが、 ;; あんまり通りそうにない意見なので、お気になさらないでください。 ;; (^_^;;; ;;; とりあえず、原理的にはもう widget の実験という意味での WEMI の意義 ;;; がなくなったことになりますね。そろそろ WEMI を解消して頂いても良い ;;; のかも知れません。 -- ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┯━…‥・きっと 真実は呆れてる・‥…━━┯━━━┯━ ┼|〓━ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yamaoka ＠ jpl.org Thu Dec 7 10:46:30 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 07 Dec 2000 10:46:30 +0900 Subject: semi-1_14 References: <87elzln340.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00709] >>>>> Daiki Ueno wrote: 守岡さん> semi-1_14 枝を作りました。 上野さん> Emacs 20.4 以降を target とするのなら、折角なので、EMIKO で 上野さん> 行っているような、純粋な widget API の使用を含めては如何でしょ 上野さん> うか。 賛成します。読みやすい綺麗なコードになるのは良いことです。 上野さん> widget.texi に記載されていない widget-convert-button を利用 上野さん> するのが純粋なのか、と言われると返答に窮しますが ^_^;; 最近 上野さん> の Gnus でも MIME button の表示には widget-convert-button を 上野さん> 介しているので、問題ないのではないかと思います。 マニュアルが整備されていない、widget のマニュアルは読んでもよくわから ない、実施例が多くない、というのが個人的には問題ですが、上野さんの例が 今後のお手本になるでしょう。 それから、 上野さん> ;; 現状の WEMI そのものを merge するというのには断固反対しま 上野さん> ;; す。 非力ながらぼくが WEMI の維持を続けている理由は、これが XEmacs で 3D ボ タンを作ることができる唯一の手段だからです。つまり見栄えだけです。でも、 これはぼくにとっては大事なことだし、他にも少しはそういう指向を持った方 がいらっしゃるでしょう。これさえ解決できるならば、現行の WEMI はさっさ と捨ててしまいたいと思っています。 Emacs 21 では face に 3D ボタンの属性を付けることができるのですが、 XEmacs で同様のことを実現する手段は、(widget-create 'push-button) と xpm-button.el を使う二つ以外にあるのでしょうか? ちなみに、以下はぼく が Emacs 21 で使っている face です。これだと `widget-convert-button' が作ったボタンが 3D で表示されます。 (set-face-attribute (setq widget-button-face (make-face 'widget-button-face)) nil :background "#a0a0d0" :foreground "Yellow" :box '(:line-width 3 :style released-button) :font "-*-times-bold-r-*-*-14-*-*-*-*-*-*-*") (set-face-attribute (setq widget-mouse-face (make-face 'widget-mouse-face)) nil :background "darkseagreen2" :foreground "Brown" :box '(:line-width 3 :style released-button :color "#a0a0d0") :font "-*-times-bold-r-*-*-14-*-*-*-*-*-*-*") (set-face-attribute (setq widget-button-pressed-face (make-face 'widget-button-pressed-face)) nil :background "#a0a0d0" :foreground "Blue" :box '(:line-width 3 :style pressed-button) :font "-*-times-bold-r-*-*-14-*-*-*-*-*-*-*") ;; 以下はおまけ。 (copy-face 'widget-button-face 'custom-button-face) (copy-face 'widget-button-pressed-face 'custom-button-pressed-face) (add-hook 'custom-mode-hook `(lambda () (setq widget-mouse-face ',widget-mouse-face)) t) -- Katsumi Yamaoka From tomo ＠ m17n.org Thu Dec 7 12:39:38 2000 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 07 Dec 2000 12:39:38 +0900 Subject: `mime-button' widget (Re: semi-1_14) In-Reply-To: tomo@m17n.org's message of "07 Dec 2000 10:27:51 +0900" References: <87elzln340.fsf@gg.bug.org> Message-ID: 現行の emiko-1_14 では `mime-button' widget は `link' widget から派生 しているようですが、これはちょっとおかしいのではないかと思います。 mime-entity button はその entity の内容を表したもので、また、一般に MIME entity は外部にある情報に対する link ではなく、内容そのものを格納 したものです。 一方、`link' は参照を表す widget-type なのではないでしょうか？ちなみに、 Emacs 21.0.91 の wid-edit.el にある `link' から派生した widget-type を 列挙すると、 info-link A link to an info file url-link A link to an www page function-link A link to an Emacs function variable-link A link to an Emacs variable file-link A link to a file emacs-library-link A link to an Emacs Lisp library file emacs-commentary-link A link to Commentary in an Emacs Lisp library file documentation-link Link type used in documentation strings があるようです。どれも参照に関するように思えます。 そういう訳で、mime-entity button の場合、`link' よりもむしろ `push-button' から派生するのが自然に思えます。 いかがでしょうか？ -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From ueno ＠ bug.org Fri Dec 8 09:35:57 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 08 Dec 2000 09:35:57 +0900 Subject: semi-1_14 In-Reply-To: References: <87elzln340.fsf@gg.bug.org> Message-ID: <87u28fbvgy.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00711] >>>>> Katsumi Yamaoka wrote: 上野> Emacs 20.4 以降を target とするのなら、折角なので、EMIKO で行って 上野> いるような、純粋な widget API の使用を含めては如何でしょうか。 山岡> 賛成します。読みやすい綺麗なコードになるのは良いことです。 実は EMIKO の実装は WEMI ではなくて Gnus の実装をお手本にしています。 これは単純に見映えだけではなくて、 semi-def.el:mime-add-url-buttons の、 (static-unless (featurep 'xemacs) (overlay-put (make-overlay beg end) 'local-map widget-keymap) のような対応の必要がないようにしたものだったと記憶しています。:-) 上野> ;; 現状の WEMI そのものを merge するというのには断固反対します。 山岡> 非力ながらぼくが WEMI の維持を続けている理由は、これが XEmacs で 山岡> 3D ボタンを作ることができる唯一の手段だからです。つまり見栄えだけ 山岡> です。でも、これはぼくにとっては大事なことだし、他にも少しはそうい 山岡> う指向を持った方がいらっしゃるでしょう。これさえ解決できるならば、 山岡> 現行の WEMI はさっさと捨ててしまいたいと思っています。 最近は theme とか skin とかいうようなものが流行りだと聞いていますが、 このような形で、SEMI の外部で好みの見映えを動的に選択することができる枠 組を作るのが良いのではないかと思います。 言い換えれば、山岡さん好みの見映えを SEMI の一部としてデフォルトで用意す るよりは、見映えの部分を再利用できるよう、別モジュールにしたほうが開発も 活発になるのではないかと。 ;; ここでいう再利用可能である、とは、 ;; ;; (1) 単純な界面を持つ ;; (2) 複数の状況 (Emacsen, device type) で、それなりに使える ;; (3) 置換、多様化が可能 ;; ;; であるという程度の意味です。 ;; 個人的な一番の理由は、既に widget を利用するよう書き直されている ;; EMIKO に、xpm-button を加えて WEMIKO と命名するのに少しだけ違和感がある ;; というか。^_^;;; 少なくとも利用者から見た場合に混乱を招くのではないか ;; と思い、先の SEMI Variants の mail を書いたわけです。 山岡> マニュアルが整備されていない、widget のマニュアルは読んでもよくわ 山岡> からない、実施例が多くない、というのが個人的には問題ですが、上野さ 山岡> んの例が今後のお手本になるでしょう。 これは作者に問い合わせるのが一番かと思いますが、次点としては、前述の ような枠組を持つ widget にかわる界面を用意する、もし可能ならその実装には 既存の widget 実装を利用するのが良いのではないかと思います。 ;; まとまった elisp を書く時間は来年度まで取れそうにないので、 ;; どなたかやって頂けると助かります。 -- Daiki Ueno From yamaoka ＠ jpl.org Fri Dec 8 11:47:15 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 08 Dec 2000 11:47:15 +0900 Subject: mule =?ISO-2022-JP?B?GyRCJEckThsoQg==?= compile References: Message-ID: >>>>> In [Wanderlust : No.06382] >>>>> Taiji.Can ＠ atesoft.advantest.co.jp wrote: 管さん> CVS の幹の latest 版を久々に mule でコンパイルしてみました。 管さん> flim/semi は 1.14 のものを使っています。 管さん> While compiling toplevel forms in file [...]/wanderlust/elmo/elmo2.el: 管さん> !! Symbol's value as variable is void ((:after)) 管さん> と言うのが出ます。:after がどうも定義されていないようです。 FLIM 1.14 の 12月4日と 11月28日の ChangeLog によると、どうも古い Emacsen はサポートされなくなったように思えます。 -- Katsumi Yamaoka From ueno ＠ bug.org Fri Dec 8 11:56:17 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 08 Dec 2000 11:56:17 +0900 Subject: `mime-button' widget (Re: semi-1_14) In-Reply-To: References: <87elzln340.fsf@gg.bug.org> Message-ID: <8766kvzkmm.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00712] >>>>> tomo ＠ m17n.org (守岡 知彦 / MORIOKA Tomohiko) wrote: > 現行の emiko-1_14 では `mime-button' widget は `link' widget から派生 > しているようですが、これはちょっとおかしいのではないかと思います。 おかしいです。 根本的には、following method では entity の text representation を要求す るのに対し、widget.texi には widget 自身の text representation について 何も記述されていないというのが問題だと思います。 WEMI では、 ;; There may be only one string "*" behind the widget button. We ;; should replace it with the string as it can be seen because it ;; will be yanked into the reply messages. (static-when (featurep 'xemacs) (let ((end (point)) extent) (insert "[" string "]") (while (setq extent (extent-at start nil nil extent)) ;; Avoid removing extents of next part. (if (eq (extent-end-position extent) end) (set-extent-endpoints extent end (point)))) (delete-region start end))) というような、XEmacs の実装に依存した処置をしているのに対し、 EMIKO では Gnus にならい、とりあえず `link' widget から派生してお茶を 濁しています。 解決案としては、 (1) そのような特質を持つ `text-button' widget を定義する。 (2) widget を包含する新しい枠組を用意する。 (3) SEMI では widget の text representation を要求しないことにする。 (4) widget.texi に widget の text representation に関する記述を加えてもらい、 XEmacs の実装をそれに合わせてもらう。 (2) については [emacs-mime-ja : No.00713] で述べた通りです。 (1) は自前でボタンを用意するのと手間はかわらなそうですし、 (3) では、Semi-gnus のような MUA は恩恵を受けられないでしょう。 個人的には (4) が良いのではないかと思うのですが、如何でしょうか？ ^_^;; ;; もしかして僕が説得するのでしょうか...(;_;) ;; P.S. ;; gnus-mime-button では、entity content の表示を popup menu により切り ;; 替えることができるのですが、最終的にはこの辺りも実装したいです。 ;; 恐らく現状の SEMI 1.14 の実装だと 2 回 popup させて 2 回 "Toggle ;; Display" を選択せねばならない場面が多くなりそうな予感がするので、 ;; 新版 calist.el の登場が待ち遠しいです。^_^;; -- Daiki Ueno From tomo ＠ m17n.org Fri Dec 8 12:13:06 2000 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 08 Dec 2000 12:13:06 +0900 Subject: mule =?ISO-2022-JP?B?GyRCJEckThsoQg==?= compile In-Reply-To: Katsumi Yamaoka's message of "08 Dec 2000 11:47:15 +0900" References: Message-ID: >>>>> In [emacs-mime-ja : No.00714] >>>>> "山岡さん" = Katsumi Yamaoka wrote: 管さん> CVS の幹の latest 版を久々に mule でコンパイルしてみました。 管さん> flim/semi は 1.14 のものを使っています。 管さん> While compiling toplevel forms in file [...]/wanderlust/elmo/elmo2.el: 管さん> !! Symbol's value as variable is void ((:after)) 管さん> と言うのが出ます。:after がどうも定義されていないようです。 山岡さん> FLIM 1.14 の 12月4日と 11月28日の ChangeLog によると、どうも 山岡さん> 古いEmacsen はサポートされなくなったように思えます。 で述べた通りです。 GNU Emacs 20.2 以前の emacsen をお使いの方は CLIME 1.14 (clime-1_14 枝) をお使いください。 ;; ただ、今入っている clime-1_14 の中身は、実際に古い emacsen での ;; check を行っている訳ではないので、不具合があれば御報告・修正お願い ;; します。一応、目標としては Nemacs, Mule 2.3, Emacs 20.1/20.2 も対象 ;; なんですが。 ;;; 現在、私は Emacs 21 と一体化した形の版（とそれに対応した RMAIL ;;; (^_^;）に集中して開発しております。flim-1_14/semi-1_14 の中身はで ;;; きるだけこれに対応するようにしたいと思っております。 ;;; ところで、Emacs 21 と一体化した FLIM/SEMI および新しい RMAIL に御 ;;; 興味の方が多ければ、これを公開しても良いと思っています。 -- 守岡 知彦 (MORIOKA Tomohiko) From Taiji.Can ＠ atesoft.advantest.co.jp Fri Dec 8 12:18:45 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Fri, 08 Dec 2000 12:18:45 +0900 Subject: mule =?ISO-2022-JP?B?GyRCJEckThsoQg==?= compile In-Reply-To: References: Message-ID: 菅です。 > 管さん> と言うのが出ます。:after がどうも定義されていないようです。 > > 山岡さん> FLIM 1.14 の 12月4日と 11月28日の ChangeLog によると、どうも > 山岡さん> 古いEmacsen はサポートされなくなったように思えます。 > > で述べた通りです。 > > GNU Emacs 20.2 以前の emacsen をお使いの方は CLIME 1.14 (clime-1_14 枝) > をお使いください。 wl ML で、うえのさんにも同じことを教えて頂きました。 ありがとうございます。利用してみます。_o_ -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From Taiji.Can ＠ atesoft.advantest.co.jp Fri Dec 8 13:40:40 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Fri, 08 Dec 2000 13:40:40 +0900 Subject: clime-1.14 In-Reply-To: References: Message-ID: 菅です。 > で述べた通りです。 > > GNU Emacs 20.2 以前の emacsen をお使いの方は CLIME 1.14 (clime-1_14 枝) > をお使いください。 と、いうことで、18.59 base の nemacs でも試してみました。 以下のエラーになりましたので、報告しておきます。 ＃mule-2.3(19.34base)では問題が出ませんでした。 /opt/nemacs/bin/emacs -batch -q -no-site-file -l FLIM-MK -f compile-flim NONE NONE \ NONE Loading /export/home/syrinx/can/work/Emacs/SEMI/tm/tm-8.8/clime-1.14/FLIM-CFG... LOADING FLIM-CFG... Loading /export/home/syrinx/can/work/Emacs/SEMI/tm/tm-8.8/clime-1.14/FLIM-ELS... LOADING FLIM-ELS... BROKEN FACILITY DETECTED: Emacs has not CCL. PREFIX=/ LISPDIR=/lib/nemacs/local.lisp : : Compiling /export/home/syrinx/can/work/Emacs/SEMI/tm/tm-8.8/clime-1.14/mime-parse.el (mime-parse-buffer)... Wrote /export/home/syrinx/can/work/Emacs/SEMI/tm/tm-8.8/clime-1.14/mime-parse.elc Compiling /export/home/syrinx/can/work/Emacs/SEMI/tm/tm-8.8/clime-1.14/mmgeneric.el... Wrong number of arguments: (lambda (type &optional parents slots) "Define TYPE as a luna-class. If PARENTS is specified, TYPE inherits PARENTS. Each parent must be name of luna-class (symbol). If SLOTS is specified, TYPE will be defined to have them." (\` (luna-define-class-function (quote (\, type)) (quote (\, (append parents (quote (standard-object))))) (quote (\, slots))))), 4 *** Error code 255 make: Fatal error: Command failed for target `elc' -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From yamaoka ＠ jpl.org Fri Dec 8 14:51:02 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 08 Dec 2000 14:51:02 +0900 Subject: semi-1_14 References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00713] >>>>> Daiki Ueno wrote: 上野さん> 最近は theme とか skin とかいうようなものが流行りだと聞いて 上野さん> いますが、このような形で、SEMI の外部で好みの見映えを動的に 上野さん> 選択することができる枠組を作るのが良いのではないかと思います。 上野さん> 言い換えれば、山岡さん好みの見映えを SEMI の一部としてデフォ 上野さん> ルトで用意するよりは、見映えの部分を再利用できるよう、別モジュー 上野さん> ルにしたほうが開発も活発になるのではないかと。 速攻で作ってみました。ぼくが使っている NEWSOS4 の古い X サーバは綺麗な widget の push-button を表示しないので、とりあえず XPM button だけです。 ;; 確か管さんもこっちがお好みでしたよね。:-) 使い方は、EMIKO 1.14 (もしくは近未来の SEMI 1.14) をインストール、添付 した wid-xpm-button.el を site-lisp/ などにコピーして byte-compile、そ して .emacs に (require 'wid-xpm-button) と書くだけです。 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: wid-xpm-button.el 型: application/octet-stream サイズ: 4144 バイト 説明: 無し URL: -------------- next part -------------- WEMI の終結宣言はもうしばらく保留しておきます。:-) -- Katsumi Yamaoka From Taiji.Can ＠ atesoft.advantest.co.jp Fri Dec 8 15:14:14 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Fri, 08 Dec 2000 15:14:14 +0900 Subject: semi-1_14 In-Reply-To: References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> Message-ID: 菅です。 > 速攻で作ってみました。ぼくが使っている NEWSOS4 の古い X サーバは綺麗な > widget の push-button を表示しないので、とりあえず XPM button だけです。 > > ;; 確か管さんもこっちがお好みでしたよね。:-) 素晴らしい。早速使わせて頂きました。 -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From Taiji.Can ＠ atesoft.advantest.co.jp Fri Dec 8 16:00:18 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Fri, 08 Dec 2000 16:00:18 +0900 Subject: semi-1_14 In-Reply-To: References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> Message-ID: 菅です。 > 速攻で作ってみました。ぼくが使っている NEWSOS4 の古い X サーバは綺麗な > widget の push-button を表示しないので、とりあえず XPM button だけです。 > > ;; 確か管さんもこっちがお好みでしたよね。:-) > > 使い方は、EMIKO 1.14 (もしくは近未来の SEMI 1.14) をインストール、添付 > した wid-xpm-button.el を site-lisp/ などにコピーして byte-compile、そ > して .emacs に > > (require 'wid-xpm-button) > > と書くだけです。 一つだけ独り言を。これは XEmacs 専用ですけど、いつか Emacs21 用のものも 出てくると良いですね。:-) -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From yamaoka ＠ jpl.org Fri Dec 8 16:11:33 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 08 Dec 2000 16:11:33 +0900 Subject: semi-1_14 References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00721] >>>>> Taiji.Can ＠ atesoft.advantest.co.jp wrote: 管さん> 一つだけ独り言を。これは XEmacs 専用ですけど、いつか Emacs21 管さん> 用のものも出てくると良いですね。:-) ええと、emacs-mime-ja の X-Mail-Count: 00711 に書いた face を使うのは? ボタンを押しても引っ込まないからダメですか? :-p XEmacs の xpm-button.el はけっこう泥臭いことをやっていて、ぼくはこうい うものが大好きなんですが、E21 用に書き直す気力はありません。 -- Katsumi Yamaoka ;; 実は Kyle さんが今いっしょうけんめいやっていたりして。:-p From Taiji.Can ＠ atesoft.advantest.co.jp Fri Dec 8 16:34:30 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Fri, 08 Dec 2000 16:34:30 +0900 Subject: semi-1_14 In-Reply-To: References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> Message-ID: 菅です。 > 管さん> 一つだけ独り言を。これは XEmacs 専用ですけど、いつか Emacs21 > 管さん> 用のものも出てくると良いですね。:-) > > ええと、emacs-mime-ja の X-Mail-Count: 00711 に書いた face を使うのは? > ボタンを押しても引っ込まないからダメですか? :-p あっと、読み飛ばしていました。_o_ これもなかなか凄いですね。 help までボタンになっちゃう。:-) > XEmacs の xpm-button.el はけっこう泥臭いことをやっていて、ぼくはこうい > うものが大好きなんですが、E21 用に書き直す気力はありません。 了解です。 ＃でも、ボタン引っ込まないか？とか色々といじっていたら、 ＃ Program received signal SIGSEGV, Segmentation fault. ＃lookup_image (f=0x4e7c00, spec=1361230204) at xfns.c:5836 ＃5836 ＃で Emacs21 が死にました。:-) 結構 Bad Window でEmacs21 は落ちますけど。:-) -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From ueno ＠ bug.org Fri Dec 8 17:28:25 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 08 Dec 2000 17:28:25 +0900 Subject: semi-1_14 In-Reply-To: References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> Message-ID: <87vgsvxqom.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00719] >>>>> Katsumi Yamaoka wrote: 上野> 最近は theme とか skin とかいうようなものが流行りだと聞いています 上野> が、このような形で、SEMI の外部で好みの見映えを動的に選択すること 上野> ができる枠組を作るのが良いのではないかと思います。 山岡> 速攻で作ってみました。ぼくが使っている NEWSOS4 の古い X サーバは綺 山岡> 麗なwidget の push-button を表示しないので、とりあえず XPM button 山岡> だけです。 すみません。どうも言いたいことが伝わらなかったようです。 widget の界面を包含するような枠組を (必要であれば luna を利用して ^_^;;) *SEMI に* 用意するということであって、 (defadvice widget-convert-button (after put-xpm-button-on-the-widget-button activate compile) ...) というような界面を持つ module を書くということではありません。 当然ながら、洗練した枠組を用意するためには、世の中に溢れている同様の 枠組を評価する必要があるでしょう。例えば、 * KDE2.0 Widget Themes: http://www.mosfet.org/themeapi/ http://www.mosfet.org/widgettheme-tutorial/develoverview.html * Swing の PLAF: http://developer.java.sun.com/developer/onlineTraining/GUI/Swing2/shortcourse.html#JFCCreatingLook * sawfish の Frame Style: http://sawfish.gnome.gr.jp/doc/sawfish-ja_66.html#SEC66 http://sawfish.gnome.gr.jp/doc/sawfish-ja_59.html#SEC59 などの各々の特性を見極めて設計して頂きたいのです。 ;; 上に挙げたものは、どれも最上位の界面は場当たりに見えるので、 ;; あまり参考にならないかも知れませんが。 如何でしょうか？ ;; なら、お前がやれ、と言われそうですが ^_^;; 先日の SASL API の件で既に ;; 精神的にはボロボロなので、どなたかやっていただけると非常にありがたい ;; です。 -- Daiki Ueno From yamaoka ＠ jpl.org Fri Dec 8 17:46:57 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 08 Dec 2000 17:46:57 +0900 Subject: semi-1_14 References: <87elzln340.fsf@gg.bug.org> <87u28fbvgy.fsf@gg.bug.org> <87vgsvxqom.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00724] >>>>> Daiki Ueno wrote: 上野さん> すみません。どうも言いたいことが伝わらなかったようです。 上野さん> widget の界面を包含するような枠組を (必要であれば luna を利 上野さん> 用して ^_^;;) *SEMI に* 用意するということであって、 いや、たぶん、間違いなく、上野さんの指向とは違うおもちゃを作っただけで あることはわかっておりました。 上野さん> 当然ながら、洗練した枠組を用意するためには、世の中に溢れてい 上野さん> る同様の枠組を評価する必要があるでしょう。例えば、 ううむ、ぼくの手には余るような気が...。(^^;;) 上野さん> ;; なら、お前がやれ、と言われそうですが ^_^;; 先日の SASL 上野さん> ;; API の件で既に精神的にはボロボロなので、どなたかやってい 上野さん> ;; ただけると非常にありがたいです。 そんなことおっしゃても、上野さん以外にはそうそういらっしゃらないんじゃ ないかと思いますけどねえ。とまれ、来週ご紹介いただいたものを見てみるこ とにします。 ;; 間もなく電源を落とさなければならばいので、これにてごめん。 -- Katsumi Yamaoka From Taiji.Can ＠ atesoft.advantest.co.jp Tue Dec 12 13:06:03 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Tue, 12 Dec 2000 13:06:03 +0900 Subject: clime-1.14 In-Reply-To: References: Message-ID: 菅です。 > と、いうことで、18.59 base の nemacs でも試してみました。 > 以下のエラーになりましたので、報告しておきます。 > ＃mule-2.3(19.34base)では問題が出ませんでした。 何だかわかりました。nemacs では ` の解釈に問題があったんですよね？ 以下のような感じで、 ` の書き方を変えました。()の閉じに問題はないとは 思いますが、確認をお願いします。 ＃ここを抜けると、次は sasl.el で # で引っ掛かった。。。 diff -u mmgeneric.el.orig mmgeneric.el --- mmgeneric.el.orig Wed Oct 25 12:52:46 2000 +++ mmgeneric.el Tue Dec 12 12:59:04 2000 @@ -74,15 +74,15 @@ ;;; (defmacro mm-expand-class-name (type) - `(intern (format "mime-%s-entity" ,type))) + (` (intern (format "mime-%s-entity" ,type)))) (defmacro mm-define-backend (type &optional parents) - `(luna-define-class ,(mm-expand-class-name type) + (` (luna-define-class ,(mm-expand-class-name type) ,(nconc (mapcar (lambda (parent) (mm-expand-class-name parent) ) parents) - '(mime-entity)))) + '(mime-entity))))) (defmacro mm-define-method (name args &rest body) (or (eq name 'initialize-instance) @@ -92,7 +92,7 @@ (cons (list (car spec) (mm-expand-class-name (nth 1 spec))) (cdr args))) - `(luna-define-method ,name ,args , ＠ body) + (` (luna-define-method ,name ,args , ＠ body)) )) (put 'mm-define-method 'lisp-indent-function 'defun) -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From Taiji.Can ＠ atesoft.advantest.co.jp Tue Dec 12 13:29:01 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Tue, 12 Dec 2000 13:29:01 +0900 Subject: clime-1.14 In-Reply-To: References: Message-ID: 菅です。 > > と、いうことで、18.59 base の nemacs でも試してみました。 > > 以下のエラーになりましたので、報告しておきます。 > > ＃mule-2.3(19.34base)では問題が出ませんでした。 > > 何だかわかりました。nemacs では ` の解釈に問題があったんですよね？ うーん。。。 ` は () でくくり、 # は ?# したり、,type なども 元のように (, type) 等としてみましたが、mule では元々のclime1-14 を コンパイルした結果とlog が違うようです。。 ＃なかなか道は険しい。 -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From yamasoto ＠ in.it.okayama-u.ac.jp Wed Dec 13 14:31:19 2000 From: yamasoto ＠ in.it.okayama-u.ac.jp (Yoshinobu YAMASOTO) Date: Wed, 13 Dec 2000 14:31:19 +0900 Subject: 無題 Message-ID: subscribe Yoshinobu YAMASOTO From yamaoka ＠ jpl.org Thu Dec 14 20:55:33 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 14 Dec 2000 20:55:33 +0900 Subject: recursive-load-depth-limit (Re: Emacs 21.0.93 =?ISO-2022-JP?B?GyRCJEcbKEI=?= tool-bar =?ISO-2022-JP?B?GyRCJCwbKEIuLi4p?= References: Message-ID: 関係あるかもしれないので、emacs-mime-ja にも Cc いたします。 >>>>> In [Wanderlust : No.06434] >>>>> Taiji.Can ＠ atesoft.advantest.co.jp wrote: 管さん> 先ほどのメイルを出してから、flim が大きく変ったなぁ,と思いなが 管さん> ら持ってきて apel/flim/semi/wl を全て消してから入れ直してみま 管さん> した。Emacs21 の分をです。... 管さん> Recursive load suspected: 管さん> が出て、まともに起動できなくなりました。。 管さん> ＃でも、XEmacs はまともに起動できて動いています。 それは Emacs 21 の `recursive-load-depth-limit' という変数に関係してい ると思います。以下は Emacs 21 の NEWS より。 ** Emacs now checks for recursive loads of Lisp files. If the recursion depth exceeds `recursive-load-depth-limit', an error is signaled. Wanderlust を Emacs 21 で make するときにこれにひっかかるので、ぼくは その対策として WL-MK に ;; FIXME: it is currently needed to byte-compile with Emacs 21. (setq recursive-load-depth-limit nil) というものを入れました。 で、最近は他の用事もあって .emacs にも同じものを入れています。 ;; "FIXME" は「これが正しいことなのかどうか自信が無いのですが」の意味 ;; でもあります。(^^;;) -- Katsumi Yamaoka From Taiji.Can ＠ atesoft.advantest.co.jp Thu Dec 14 21:05:12 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Thu, 14 Dec 2000 21:05:12 +0900 Subject: recursive-load-depth-limit (Re: Emacs 21.0.93 =?ISO-2022-JP?B?GyRCJEcbKEI=?= tool-bar =?ISO-2022-JP?B?GyRCJCwbKEIuLi4p?= In-Reply-To: References: Message-ID: 菅です。 > 管さん> Recursive load suspected: > > 管さん> が出て、まともに起動できなくなりました。。 > 管さん> ＃でも、XEmacs はまともに起動できて動いています。 > > それは Emacs 21 の `recursive-load-depth-limit' という変数に関係してい > ると思います。以下は Emacs 21 の NEWS より。 > > ** Emacs now checks for recursive loads of Lisp files. If the > recursion depth exceeds `recursive-load-depth-limit', an error is > signaled. エラーは出なくなりました。ありがとうございます。_o_ > Wanderlust を Emacs 21 で make するときにこれにひっかかるので、ぼくは > その対策として WL-MK に > > ;; FIXME: it is currently needed to byte-compile with Emacs 21. > (setq recursive-load-depth-limit nil) > > というものを入れました。 そのようですね。確認しました。 -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From yamaoka ＠ jpl.org Fri Dec 15 21:49:00 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Dec 2000 21:49:00 +0900 Subject: CLIME 1.14 (Re: mule =?ISO-2022-JP?B?GyRCJEckThsoQg==?= compile) References: Message-ID: >>>>> In [emacs-mime-ja : No.00716] >>>>> tomo ＠ m17n.org (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡さん> GNU Emacs 20.2 以前の emacsen をお使いの方は CLIME 1.14 守岡さん> (clime-1_14 枝) をお使いください。 守岡さん> ;; ただ、今入っている clime-1_14 の中身は、実際に古い 守岡さん> ;; emacsen でのcheck を行っている訳ではないので、不具合があ 守岡さん> ;; れば御報告・修正お願いします。一応、目標としては Nemacs, 守岡さん> ;; Mule 2.3, Emacs 20.1/20.2 も対象なんですが。 clime-1_14 を最新の flim-1_14 に sync させてみました。ですが、まだ問題 があります。 Nemacs 3.3.2 最新の APEL (Nemacs で clime-1_14 を使うために必要です) tm-8.8 という構成で Wanderlust でメールを送信しようとすると、以下の (よくあり がちな ^^;;) エラーが起こります。 Signalling: (invalid-function (macro lambda (entity) (list (quote aref) entity 2))) signal(invalid-function ((macro lambda (entity) (list (quote aref) entity 2)))) (condition-case ...) (let* ...) (wl-smtp-extension-bind ...computing arguments...) (if ...) (when ...computing arguments...) (let ...) (as-binary-process ...computing arguments...) (let ...) (save-excursion ...) (unwind-protect ...) (if ...) (let* ...) wl-draft-send-mail-with-smtp() このエラーは smtp-send-buffer に起因するもので、これが起きた後で手動で smtp.el を byte-compile すれば、以後は問題無く動作するようになります。 つまり smtp.elc を make するときに、どこかで定義されている macro が無 いわけですが、それが何なのかまだ見つけることができません。一方、上位の Emacsen で make した場合は、初めからこのようなエラーは起きません。 ぼくは来週再びデバッグを行なうつもりですが、もし原因を見つけられた方は 直してしまって下さい。 今後も clime-1_14 の flime-1_14 への sync を続けることができるかどうか は、皆様のご協力が得られるかどうかにかかっています。ぼくはたまたま興味 本位で初めてみただけですし、元々能力も無いので、すぐに果ててしまうかも しれません。(^^;;) ;; なかやまさん、tamago4 の件は症状を再現できました。ですが、原因究明 ;; に割ける時間が無くなってしまったので、これも来週にします。ごめんな ;; さい。 ;;; 菅さんにはいろいろ協力していただきました。ありがとうございました。 -- Katsumi Yamaoka From ueno ＠ bug.org Fri Dec 15 23:34:27 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 15 Dec 2000 23:34:27 +0900 Subject: CLIME 1.14 (Re: mule =?iso-2022-jp?b?GyRCJEckThsoQg==?= compile) In-Reply-To: References: Message-ID: <87r93921os.fsf@gg.bug.org> >>>>> In [Wanderlust : No.06455] >>>>> Katsumi Yamaoka wrote: 山岡> clime-1_14 を最新の flim-1_14 に sync させてみました。ですが、まだ 山岡> 問題があります。 山岡> という構成で Wanderlust でメールを送信しようとすると、以下の (よく 山岡> ありがちな ^^;;) エラーが起こります。 山岡> このエラーは smtp-send-buffer に起因するもので、これが起きた後で手 山岡> 動でsmtp.el を byte-compile すれば、以後は問題無く動作するようにな 山岡> ります。つまり smtp.elc を make するときに、どこかで定義されている 山岡> macro が無いわけですが、それが何なのかまだ見つけることができません。 山岡> 一方、上位のEmacsen で make した場合は、初めからこのようなエラーは 山岡> 起きません。ぼくは来週再びデバッグを行なうつもりですが、もし原因を 山岡> 見つけられた方は直してしまって下さい。 手元に Nemacs 3.3.2 を入れて試してみましたが、bytecomp-2.07 を使えば きちんと展開されるようです。 ;; ちなみに bytecomp-2.07 は skk/main/patch/e18 以下から入手しました。 ;; これが原因だとすると toplevel 以外で luna-define-internal-accessors ;; を使うものは全滅のような気がするのですが。 Wanderlust をインストールするのは面倒なので、 send-mail-function に CLIME の smtpmail-send-it を設定して mail-mode で 送信してみましたが、特に問題は発生しませんでした。 山岡> 今後も clime-1_14 の flime-1_14 への sync を続けることができるかど 山岡> うかは、皆様のご協力が得られるかどうかにかかっています。ぼくはたま 山岡> たま興味本位で初めてみただけですし、元々能力も無いので、すぐに果て 山岡> てしまうかもしれません。(^^;;) ところで、最近の flim-1_14 枝の変更は、[emacs-mime-ja : No.00701] で守岡 さんが仰っているように、poe/emu 関連の code への依存をなくすものが殆どで はないかと思うのですが、他に何か目新しい変更がありましたでしょうか？ -- Daiki Ueno From yamaoka ＠ jpl.org Mon Dec 18 16:06:14 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Mon, 18 Dec 2000 16:06:14 +0900 Subject: CLIME 1.14 (Re: mule =?ISO-2022-JP?B?GyRCJEckThsoQg==?= compile) References: <87r93921os.fsf@gg.bug.org> Message-ID: <283dfm2opl.wl@jpl.org> ! Nemacs ユーザのみなさま: ! CLIME 1.14 を Nemacs で使う場合、bytecomp-2.07 が必須のようです。 山岡です。遅くなりました。 >>>>> In [emacs-mime-ja : No.00732] >>>>> Daiki Ueno wrote: 山岡> という構成で Wanderlust でメールを送信しようとすると、以下の (よ 山岡> くありがちな ^^;;) エラーが起こります。 [...] 上野さん> 手元に Nemacs 3.3.2 を入れて試してみましたが、bytecomp-2.07 上野さん> を使えばきちんと展開されるようです。 ご指摘ありがとうございます。ぼくも bytecomp-2.07 を使えば問題無いこと を確認しました。 上野さん> ;; ちなみに bytecomp-2.07 は skk/main/patch/e18 以下から入手 上野さん> ;; しました。 他に単品でも入手可能でした。 ftp://ftp.sra.co.jp/pub/gnu/jp/bytecomp/bytecomp-2.07.tar.Z Mule 1 をお使いの方はいらっしゃらないようですが、一応これも。 ftp://ftp.sra.co.jp/pub/gnu/jp/bytecomp/bytecomp-2.07-mule1.patch.gz 上野さん> ;; これが原因だとすると toplevel 以外で 上野さん> ;; luna-define-internal-accessors を使うものは全滅のような気 上野さん> ;; がするのですが。 おそらくそうですね。 [...] 上野さん> ところで、最近の flim-1_14 枝の変更は、[emacs-mime-ja : 上野さん> No.00701] で守岡さんが仰っているように、poe/emu 関連の code 上野さん> への依存をなくすものが殆どではないかと思うのですが、他に何か 上野さん> 目新しい変更がありましたでしょうか？ いえ、本質的な内容に関する変更は無いと思います。 最近の Emacsen に比べて Nemacs などの古いものは、機能が少ない代りに動 作が極めて軽快で、遅いマシンでは有用であることを改めて認識しました。 しかし、今回思ったもう一つのことは、old Emacsen 対応を２１世紀にも持っ ていって延々と開発を続けるために割く時間があるならば、もっと新しいこと に注力すべきではないか、ということです。 少なくとも Wanderlust の完成度は水準に達していると思うので、どうしても 古い Emacsen を使いたい人が固定的に使い続けていく分には問題無いわけで すし。 そういうわけで、山岡個人としては clime-1_14 の flim-1_14 への sync は FLIM 1.14 公式に世に出るまで、できるところだけ行なう、ということにしよ うと思います。もちろん、もっと積極的に開発を進めたいという方がいらっしゃ れば、それを讃えこそすれ反対はしません。:-) -- Katsumi Yamaoka From tomo ＠ m17n.org Wed Dec 20 17:40:41 2000 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 20 Dec 2000 17:40:41 +0900 Subject: FLIM 1.14.0 =?ISO-2022-JP?B?KBskQj83JU44fRsoQik=?= Message-ID: [Status] alpha [Recommended environment] APEL: 10.2 (or latest CVS snapshot) [Changes from FLIM-Chao 1.14.1] 2000-12-20 MORIOKA Tomohiko * FLIM: Version 1.14.0 (Ninokuchi) released. * mime.el (mime-entity-media-type): Add DOC. (mime-entity-media-subtype): Add DOC. (mime-entity-parameters): Add DOC. (mime-entity-type/subtype): Add DOC. * FLIM-API.en: Add some usages. (mime-entity-media-type): New description. (mime-entity-media-subtype): Likewise. (mime-entity-type/subtype): Likewise. (mime-entity-parameters): Likewise. 2000-12-20 MORIOKA Tomohiko * eword-encode.el (eword-encode-text): Specify `mode' of `encoded-text-encode-string'. * mel.el (encoded-text-encode-string): Add optional argument `mode'; use `base64-encode-string' directly for "B"-encoding. 2000-12-20 MORIOKA Tomohiko * FLIM-API.en: Renamed from FLIM-1.14-API.en; reordered and add some sections. * mime.el (mime-entity-set-content-type): Add DOC. (mime-entity-set-encoding): Add DOC. * mime-def.el (mime-content-type-subtype): Fix DOC. (mime-content-type-parameters): Fix DOC. 2000-12-19 MORIOKA Tomohiko * FLIM-1.14-API.en: New file. * smtp.el (smtp-open-connection-function): Add autoload cookie. * qmtp.el (qmtp-open-connection-function): Add autoload cookie. * mime.el (mime-entity-children): Add DOC. (mime-entity-node-id): Add DOC. (mime-entity-content-type): Add DOC. (mime-entity-content-disposition): Add DOC. (mime-entity-encoding): Add DOC. 2000-12-19 MORIOKA Tomohiko * mime.el (mime-encode-field-body): Add autoload setting. * eword-encode.el (mime-encode-field-body): Renamed from `eword-encode-field-body'; declare `eword-encode-field-body' as obsolete alias. (mime-encode-header-in-buffer): Use `mime-encode-field-body' instead of `eword-encode-field-body'. 2000-12-19 MORIOKA Tomohiko * mime.el (mime-encode-header-in-buffer): Renamed from `eword-encode-header'. * mmdbuffer.el: Deleted. * mime-def.el (mime-header): New group. (mime-field-decoding-max-size): New user option [moved from eword-decode.el]. (mime-field-encoding-method-alist): New user option [moved from eword-encode.el]. * eword-encode.el (eword-field-encoding-method-alist): Moved to mime-def.el and renamed to `mime-field-encoding-method-alist'. (mime-header-charset-encoding-alist): Renamed from `eword-charset-encoding-alist'. (mime-header-default-charset-encoding): New variable. (ew-find-charset-rule): Use `mime-header-default-charset-encoding'. (eword-in-subject-p): Declare as obsolete function. (mime-encode-header-in-buffer): Renamed from `eword-encode-header'; declare `eword-encode-header' as obsolete alias. * eword-decode.el (eword-max-size-to-decode): Moved to mime-def.el and renamed to `mime-field-decoding-max-size'. (mime-header-lexical-analyzer): Renamed from `eword-lexical-analyzer'; switch to variable. * FLIM-ELS (flim-modules): Add `raw-io'. 2000-12-19 MORIOKA Tomohiko * eword-encode.el (eword-encode-default-start-column): Switch to variable. 2000-12-19 MORIOKA Tomohiko * raw-io.el (start-process): New function. (binary-start-process-shell-command): New function. 2000-12-17 MORIOKA Tomohiko * mel-g.el (gzip64-external-encode-region): Don't use `as-binary-process'; comment out code to regularize line break code for OS/2 [if it is needed, it is better to implement by coding-system]. (gzip64-external-decode-region): Don't use `as-binary-process'. (mime-write-decoded-region): Likewise. * mime-parse.el: Require `luna'. 2000-12-16 MORIOKA Tomohiko * eword-encode.el (eword-encode-divide-into-charset-words): Use `aref' instead of `sref'. (ew-encode-rword-1): Use `1+' instead of `char-next-index'. (eword-encode-phrase-to-rword-list): Use `find-charset-string' instead of `find-non-ascii-charset-string'. (eword-encode-addr-seq-to-rword-list): Don't use `butlast'. (eword-encode-header): Use `find-charset-region' instead of `find-non-ascii-charset-string'. * mel.el: Require `raw-io'. * mime-def.el (binary-insert-file-contents): Moved to raw-io.el. (binary-write-region): Likewise. * mmbabyl.el (mime-write-entity): Use `raw-message-write-region' instead of `write-region-as-raw-text-CRLF'. * raw-io.el: New file. * smtpmail.el: - Require `raw-io'. - Delete definition of obsolete variable aliases for XEmacs. (smtpmail-send-queued-mail): Use `binary-find-file-noselect' instead of `find-file-noselect-as-binary'. * smtp.el (smtp-open-connection-function): Use `binary-open-network-stream' instead of `open-network-stream' as initial value. (smtp-open-connection): Don't guard as `binary'. * qmtp.el (qmtp-open-connection-function): Use `binary-open-network-stream' instead of `open-network-stream' as initial value. (qmtp-send-buffer): Don't guard as `binary'. 2000-12-15 MORIOKA Tomohiko * mime/eword-decode.el: Don't use `define-obsolete-function-alias'; so `eword-decode-header' is deleted. * mime/mmexternal.el: Don't require `pces'. 2000-12-15 TAKAHASHI Kaoru * Makefile (tar): Use `cvs tag -R' instead of `cvs tag -RF'. 2000-12-15 MORIOKA Tomohiko * mime-def.el (char-int): New alias. * eword-encode.el (eword-encode-divide-into-charset-words): Don't use `char-length' and `char-next-index'. 2000-12-15 Katsumi Yamaoka * eword-decode.el: Fix typo in doc-string of `mime-set-field-decoder'. 2000-12-15 MORIOKA Tomohiko * mel.el: Don't require `path-util'. 2000-12-15 MORIOKA Tomohiko * std11.el, smtpmail.el, mime-def.el: Don't require `poe'. * mel.el: Don't require `poem'. 2000-12-14 MORIOKA Tomohiko * mmexternal.el (mime-write-entity): Don't use `write-region-as-raw-text-CRLF'. (mmexternal-require-buffer): Use `binary-insert-file-contents' instead of `insert-file-contents-as-binary'. (mime-write-entity-body): Use `binary-write-region' instead of `write-region-as-binary'. * smtpmail.el (smtpmail-send-it): Use `binary-write-region' instead of `write-region-as-binary'. * smtp.el (smtp-open-connection): Don't use `as-binary-process'. * mel.el (mime-insert-encoded-file of "base64"): Use `binary-insert-file-contents' instead of `insert-file-contents-as-binary'. (mime-insert-encoded-file of "7bit"): Use `binary-insert-file-contents' instead of `insert-file-contents-as-binary'. (mime-write-decoded-region of "7bit"): Use `binary-write-region' instead of `write-region-as-binary'. * mmbuffer.el (mime-write-entity-body): Use `binary-write-region' instead of `write-region-as-binary'. (mime-write-entity): Don't use `write-region-as-raw-text-CRLF'. * mime-def.el: Don't require `poem'. (binary-insert-file-contents): New function. (binary-write-region): New function. * mel-u.el (uuencode-external-encode-region): Don't use `as-binary-process'. (uuencode-external-decode-region): Don't use `as-binary-process' and `as-binary-input-file'. (mime-write-decoded-region): Don't use `as-binary-process'. * mel-q-ccl.el (quoted-printable-ccl-insert-encoded-file): Don't use `insert-file-contents-as-coding-system'. (quoted-printable-ccl-write-decoded-region): Don't use `write-region-as-coding-system'. * mel-b-ccl.el (base64-ccl-insert-encoded-file): Don't use `insert-file-contents-as-coding-system'. (base64-ccl-write-decoded-region): Don't use `write-region-as-coding-system'. * std11.el: Don't require `poem'. (std11-parse-ascii-token): Don't use `find-non-ascii-charset-string'. * qmtp.el: Don't require `poem'. (qmtp-send-buffer): Don't use `as-binary-process'. 2000-12-14 MORIOKA Tomohiko * mime-def.el, qmtp.el, smtp.el, smtpmail.el, std11.el: Require `custom' instead of `pcustom'. 2000-12-12 Daiki Ueno * sasl.el: Rewrite with luna. 2000-12-06 Daiki Ueno * FLIM-ELS: Don't install md5-dl.el, md5-el.el, sha1-dl.el and sha1-el.el if the running emacs has builtin message digest functions. * md5-dl.el, sha1-dl.el: Don't bind `dynamic-link' and `dynamic-call'. * md5.el (md5-dl-module): Moved from md5-dl.el. * sha1.el: Don't bind `sha1-string'. 2000-12-04 Daiki Ueno * README.ja, README.en (load-path): Remove section. (What's FLIM): Specify prerequisite version of Emacsen. 2000-11-21 Daiki Ueno * sasl.el (sasl-client-set-encoder): New function. (sasl-client-set-decoder): New function. (sasl-client-encoder): New function. (sasl-client-decoder): New function. * sasl-digest.el: Require 'cl' when compiling. (sasl-digest-md5-signing-encode-magic): New constant. (sasl-digest-md5-signing-decode-magic): New constant. (sasl-digest-md5-htonl-string): New function. (sasl-digest-md5-make-integrity-encoder): New function. (sasl-digest-md5-make-integrity-decoder): New function. (sasl-digest-md5-ha1): New function. (sasl-digest-md5-response-value): Accept the 1st argument `ha1'. (sasl-digest-md5-response): Use `sasl-digest-md5-ha1'. - Set integrity encoder and decoder of the client. * smtp.el: Require `luna'. (smtp-read-response): Accept `smtp-connection' object rather than process-object. (smtp-send-command): Likewise. (smtp-send-data): Likewise. 2000-11-10 Daiki Ueno * tests/test-sasl.el (test-sasl-digest-md5-imap): New testcase. (test-sasl-digest-md5-acap): New testcase. 2000-11-10 Daiki Ueno * lunit.el (lunit-make-test-suite-from-class): New function. (lunit-class): Abolish. (lunit-test-results-buffer): Abolish. * FLIM-ELS (check-flim): New function. * Makefile (check): New target. * tests: New directory. 2000-11-09 Daiki Ueno * lunit.el (lunit-test-method-regexp): New variable. (lunit-class): New function. 2000-11-09 Daiki Ueno * lunit.el: New file. 2000-12-13 Kenichi Handa * luna.el: Fix and add DOCs and comments; fix coding style. 2000-12-09 MORIOKA Tomohiko * mmbuffer.el (mmbuffer-parse-multipart): Add new optional argument `representation-type'. (mmbuffer-parse-encapsulated): Likewise. 2000-12-07 MORIOKA Tomohiko * mmexternal.el: Must require `mmgeneric'. * sha1.el: Don't use `defun-maybe'. 2000-12-04 Daiki Ueno * luna.el (luna-class-find-functions): Don't quote colon keywords. (luna-send): Ditto. (luna-call-next-method): Ditto. 2000-11-28 Daiki Ueno * luna.el: Don't require `static'. (luna-define-class-function): Don't bind colon keywords. (luna-class-find-functions): Quote colon keywords. (luna-send): Likewise. (luna-call-next-method): Likewise. 2000-11-12 Daiki Ueno * luna.el (luna-define-method): Clear method cache. (luna-apply-generic): New function. (luna-define-generic): Use `luna-apply-generic' instead of `luna-send'. 2000-12-04 Daiki Ueno * smtpmail.el (smtpmail-send-it): Use `smtp-send-buffer' instead of `smtp-via-smtp'. (smtpmail-send-queued-mail): Ditto. 2000-11-24 MORIOKA Tomohiko * FLIM-MK (compile-flim): Compile `flim-version-specific-modules'. (install-flim): Install `flim-version-specific-modules' to `FLIM_VERSION_SPECIFIC_DIR'. (compile-flim-package): Compile `flim-version-specific-modules'. (install-flim-package): Install `flim-version-specific-modules'. * FLIM-ELS (flim-modules): Add `mime-conf' instead of `mailcap'. (flim-version-specific-modules): New variable; specify `mailcap'. * FLIM-CFG (FLIM_VERSION_SPECIFIC_DIR): New variable. * mailcap.el: Completely rewrote to use mime-conf.el. * mime-conf.el: New file. 2000-11-16 Kenichi OKADA * sasl-digest.el (sasl-digest-md5-response): Fix typo. 2000-11-12 Daiki Ueno * smtp.el (smtp-primitive-data): Use `beginning-of-line' instead of `forward-char'. (smtp-read-response): Don't bind `case-fold-search'. (smtp-send-data): Don't save excursion. 2000-11-10 Daiki Ueno * sasl-digest.el (sasl-digest-md5-challenge): Abolish. (sasl-digest-md5-syntax-table): Rename from `sasl-digest-md5-parse-digest-challenge-syntax-table'. (sasl-digest-md5-parse-string): Rename from `sasl-digest-md5-parse-digest-challenge'; only return a property list. (sasl-digest-md5-challenge): Abolish. (sasl-digest-md5-build-response-value-1): Abolish. (sasl-digest-md5-response-value): Define as function. (sasl-digest-md5-response): Rewrite. 2000-11-07 Kenichi OKADA * sasl.el (sasl-login-response-1): Fix. (sasl-login-response-2): Fix. 2000-11-07 Daiki Ueno * smtp.el (smtp-sasl-properties): New user option. (smtp-sasl-user-realm): Abolish. 2000-11-05 Daiki Ueno * qmtp.el (qmtp-send-package): Don't check "K" reply per recipient. (qmtp-via-smtp): Mark as obsolete. (qmtp-send-buffer): New function. * sasl.texi: New file. 2000-11-05 Daiki Ueno * sasl.el (sasl-step-data): New function. (sasl-step-set-data): New function. 2000-11-04 Daiki Ueno * sasl.el: Don't require 'poe' - Rename `sasl-*instantiator*' to `sasl-*client*'. - Rename `sasl-*authenticator*' to `sasl-*mechanism*'. - Rename `sasl-*continuations*' to `sasl-*steps*'. (sasl-make-client): Accept 1st argument `mechanism'. (sasl-next-step): Rename from `sasl-evaluate-challenge'. 2000-11-04 Daiki Ueno * sasl.el (sasl-make-instantiator): Define as function. (sasl-instantiator-name): Ditto. (sasl-instantiator-service): Ditto. (sasl-instantiator-server): Ditto. (sasl-instantiator-set-properties): Ditto. (sasl-instantiator-set-property): Ditto. (sasl-instantiator-property): Ditto. (sasl-instantiator-properties): Ditto. (sasl-authenticator-mechanism): Ditto. (sasl-authenticator-continuations): Ditto. 2000-11-02 Daiki Ueno * sasl.el: Rename `sasl-*principal*' to `sasl-*instantiator*'. (sasl-make-instantiator): Abolish optional 4th argument. (sasl-instantiator-set-properties): New function. (sasl-instantiator-put-property): New function. (sasl-instantiator-property): New function. (sasl-instantiator-properties): New function. * smtp.el (smtp-sasl-user-name): Rename from `smtp-sasl-principal-user'. (smtp-sasl-user-realm): Rename from `smtp-sasl-principal-realm'. 2000-11-02 Daiki Ueno * sasl.el (sasl-mechanisms): Add `LOGIN' and `ANONYMOUS'. (sasl-mechanism-alist): Likewise. (sasl-error): Define. (sasl-login-continuations): New variable. (sasl-login-response-1): New function. (sasl-login-response-2): New function. (sasl-anonymous-continuations): New variable. (sasl-anonymous-response): New function. * smtp.el (smtp-error): Define. (smtp-via-smtp): Use it. 2000-11-02 Daiki Ueno * smtp.el (smtp-via-smtp): Mark as obsolete. (smtp-send-buffer): Rename from `smtp-via-smtp'. 2000-11-02 Daiki Ueno * sasl.el (sasl-make-authenticator): Allocate a freshly generated symbol for each continuation. 2000-11-02 Daiki Ueno * sasl-digest.el (sasl-digest-md5-response-1): Rename from `sasl-digest-md5-digest-response'. (sasl-digest-md5-response-2): New alias. (sasl-digest-md5-parse-digest-challenge): Save excursion. * sasl.el (sasl-mechanism-alist): Rename from `sasl-mechanisms'. (sasl-mechanisms): New variable. (sasl-find-authenticator): Check `sasl-mechanisms' rather than `sasl-mechanism-alist'. * smtp.el (smtp-submit-package): Use `smtp-primitive-ehlo'. (smtp-primitive-auth): Check authenticator. 2000-11-02 Daiki Ueno * FLIM-ELS (hmac-modules): New variable. (flim-modules): Move HMAC modules to `hmac-modules' - Add `sasl-digest'. * smtp.el (smtp-sasl-principal-realm): New user option. * sasl.el (sasl-plain-response): New function. (sasl-mechanisms): Add `DIGEST-MD5' and `PLAIN'. (sasl-unique-id-function): New variable. (sasl-plain-continuations): New variable. (sasl-unique-id): New function. (sasl-unique-id-char): New variable. * sasl-digest.el: New file. 2000-11-01 Daiki Ueno * smtp.el: Bind `sasl-mechanisms'; add autoload settings for `sasl-make-principal', `sasl-find-authenticator', `sasl-authenticator-mechanism-internal' and `sasl-evaluate-challenge'. (smtp-use-sasl): New user option. (smtp-sasl-principal-name): New user option. (smtp-sasl-mechanisms): New user option. (smtp-submit-package): Call `smtp-primitive-starttls' and `smtp-primitive-auth'. (smtp-primitive-ehlo): Don't modify the rest of a extension line. (smtp-primitive-auth): New function. (smtp-primitive-starttls): Check the response code. * sasl.el: New implementation. * sasl-cram.el: New file. * FLIM-ELS (flim-modules): Add `md5', `md5-el', `md5-dl', `hex-util', `hmac-def', `hmac-md5', `sasl' and `sasl-cram'. 2000-11-01 Daiki Ueno * smtp.el: Add autoload settings for `starttls-open-stream' and `starttls-negotiate'. (smtp-connection-set-extensions-internal): New macro. (smtp-connection-extensions-internal): New macro. (smtp-make-connection): Set the `extension' slot to nil. (smtp-primitive-ehlo): New function. (smtp-submit-package): Rename from `smtp-commit'. (smtp-submit-package-function): Rename from `smtp-commit-function'. (smtp-primitive-starttls): New function. (smtp-extensions): New group. (smtp-use-8bitmime): New variable. (smtp-use-size): New variable. (smtp-use-starttls): New variable. (smtp-via-smtp): Bind `smtp-open-connection-function'. 2000-10-31 Daiki Ueno * smtp.el: New implementation. 2000-08-16 Daiki Ueno * FLIM-ELS (flim-modules): Add `qmtp'. * qmtp.el: New file. 2000-08-28 Yuuichi Teranishi * eword-encode.el (eword-encode-mailboxes-to-rword-list): New inline function. (eword-encode-address-to-rword-list): Ditto. (eword-encode-addresses-to-rword-list): Use `eword-encode-address-to-rword-list' instead of `eword-encode-mailbox-to-rword-list'. * std11.el (std11-address-string): Fix for group list. 2000-08-10 MORIOKA Tomohiko * mmgeneric.el: Enclose definition of class `mime-entity' and its internal accessors by `eval-and-compile'. * luna.el: Define `luna-class-name' before it is used in macros. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/flim/flim-1.14/ -------------- next part -------------- -- tomo. From tomo ＠ m17n.org Wed Dec 20 17:46:21 2000 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 20 Dec 2000 17:46:21 +0900 Subject: SEMI 1.14.0 =?ISO-2022-JP?B?KBskQkYwNjYbKEIp?= Message-ID: [Status] alpha [Required Environment] APEL: 9.22 (or later) FLIM: 1.14.0 [Changes from REMI 1.14.2] 2000-12-20 MORIOKA Tomohiko * SEMI: Version 1.14.0 (Iburihashi) released. 2000-12-19 MORIOKA Tomohiko * mime-edit.el (mime-edit-mime-version-field-for-message/partial): Use `mime-encode-field-body' instead of `eword-encode-field-body'. 2000-12-19 MORIOKA Tomohiko * mime-edit.el (mime-edit-translate-header): Use `mime-encode-header-in-buffer' instead of `eword-encode-header'. (mime-edit-encrypt-pgp-mime): Likewise. (mime-edit-translate-single-part-tag): Likewise. 2000-12-17 MORIOKA Tomohiko * postpet.el: Require `mime'. * pgg-parse.el (pgg-format-key-identifier): Don't use `string-to-int-list'. (pgg-read-bytes): Likewise. (pgg-read-body): Likewise. 2000-12-16 MORIOKA Tomohiko * smime.el: Require `raw-io'. (smime-process-region): Use `binary-start-process-shell-command'. * pgg-pgp5.el (pgg-pgp5-process-region): Use `binary-start-process-shell-command'. * pgg-pgp.el (pgg-pgp-process-region): Use `binary-start-process-shell-command'. * pgg-gpg.el (pgg-gpg-process-region): Use `binary-start-process'. 2000-12-15 MORIOKA Tomohiko * pgg-def.el: Require `custom' instead of `pcustom'. 2000-12-15 TAKAHASHI Kaoru * Makefile (tar): Use `cvs tag -R' instead of `cvs tag -RF'. 2000-12-15 MORIOKA Tomohiko * smime.el (smime-process-region): Don't use `as-binary-process'. (smime-verify-region): Use `binary-write-region' instead of `write-region-as-binary'; use `binary-insert-file-contents' instead of `insert-file-contents-as-binary'. * semi-def.el: Don't require `poe'. * pgg-pgp5.el (pgg-pgp5-process-region): Don't use `as-binary-process'. (pgg-scheme-verify-region): Use `binary-write-region' instead of `write-region-as-binary'. (pgg-scheme-snarf-keys-region): Don't use `write-region-as-raw-text-CRLF'. * pgg-pgp.el (pgg-pgp-process-region): Don't use `as-binary-process'. (pgg-scheme-verify-region): Use `binary-write-region' instead of `write-region-as-binary'. (pgg-scheme-snarf-keys-region): Don't use `write-region-as-raw-text-CRLF'. * pgg-parse.el: Don't require `poem'; require `custom' instead of `pcustom'. * pgg-gpg.el (pgg-gpg-process-region): Don't use `as-binary-output-file' and `insert-file-contents-as-raw-text-CRLF'. * mime-view.el: Don't require `emu'. (mouse-button-3): New variable. * mime-play.el (mime-store-message/partial-piece): Use `binary-insert-file-contents' instead of `insert-file-contents-as-binary'; don't use `as-binary-input-file'; use `binary-write-region' instead of `write-region-as-binary'. 2000-12-07 MORIOKA Tomohiko * mime-w3.el: Avoid error even if `w3' is not found. 2000-11-26 MORIOKA Tomohiko * mime-view.el: Use `mime-conf' instead of `mailcap'. * mime-play.el (mime-activate-mailcap-method): Use `mime-format-mailcap-command' instead of `mailcap-format-command'. 2000-10-19 Takanori Saneto * pgg-pgp.el (pgg-pgp-process-region): bind process-environment locally so that setenv's effect won't last forever. pgg-pgp5.el (pgg-pgp5-process-region): Ditto. 2000-09-29 MORIOKA Tomohiko * mime-edit.el (mime-file-types): Fix to use application/msword instead of application/winword. 2000-08-11 MORIOKA Tomohiko * mime-view.el (mime-display-text/plain): Display warning message when `mime-insert-text-content' fails. 2000-08-04 Daiki Ueno * pgg-gpg.el (pgg-gpg-process-region): Don't bind coding-system-for-read. 2000-07-04 Yuuichi Teranishi * mime-image.el (mime-image-insert) [XEmacs]: Insert `string' only if it is non-nil. 2000-06-27 Daiki Ueno * mime-image.el (mime-image-insert): Synch with the latest image.el. (mime-display-image): Don't pass underlying string "x". 2000-06-09 Daiki Ueno * mime-edit.el (mime-edit-insert-key): Insert a text tag when the buffer has any trailing text. 2000-06-05 Shugo Maeda * pgg-gpg.el (pgg-scheme-insert-key): Don't quote user id. 2000-05-21 Daiki Ueno * pgg-gpg.el (pgg-gpg-process-region): Abolish redundant nconc. 2000-05-16 Daiki Ueno * mime-image.el (mime-image-create) [XEmacs]: Don't call `make-image-instance' directly. 2000-05-02 Daiki Ueno * pgg-gpg.el (pgg-scheme-encrypt-region): Don't quote recipient; concatenate all arguments destructively. 2000-04-13 Daiki Ueno * pgg-gpg.el: Fix author's mailing address. (pgg-gpg-process-region): Add --output option; set status fd to 2. (pgg-gpg-possibly-cache-passphrase): New function. (pgg-gpg-shell-file-name): Abolish. (pgg-gpg-shell-command-switch): Abolish. (pgg-scheme-lookup-key): Work on temp buffer. 2000-03-01 Yoshiki Hayashi * mime-image.el (mime-display-image): Don't wait for redisplay. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/semi/semi-1.14-for-flim-1.14/ -------------- next part -------------- -- tomo. From tomo ＠ m17n.org Wed Dec 20 18:05:42 2000 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 20 Dec 2000 18:05:42 +0900 Subject: EMH 1.14.0 Message-ID: [Status] alpha [Required Environment] APEL: 9.22 or later FLIM: 1.14.0 or later SEMI: 1.14.0 or later [Changes] 2000-12-20 MORIOKA Tomohiko * EMH: Version 1.14.0 released. * README.en (What's EMH?): Modify for FLIM/SEMI 1.14. 2000-12-19 MORIOKA Tomohiko * EMH-ELS: Don't require `mh-e'. (emh-modules): Add `emh-def'. * emh-face.el (emh-set-face-foreground): Use nil as variable of `condition-case'. * emh-comp.el (emh-forward): Delete unused local variable `msubtype'. 2000-12-17 MORIOKA Tomohiko * emh-def.el: New file. * emh.el (mh-display-msg): Use `raw-text-insert-file-contents' instead of `insert-file-contents-as-raw-text'; use `mime-decode-header-in-buffer' instead of `eword-decode-header'. (emh-request-partial-message): Use `raw-text-insert-file-contents' instead of `insert-file-contents-as-raw-text'. * emh-face.el: Require `emh-def' and `std11'. * emh-comp.el: Require `emh-def'. (emh-edit-again): Use `binary-insert-file-contents'; don't use `as-binary-input-file'. 2000-12-16 MORIOKA Tomohiko * emh-setup.el (emh-setup-mh-draft-setting): Use `mime-decode-header-in-buffer' instead of `eword-decode-header'. 2000-05-25 Tanaka Akira * README.en: Update for CVS via SSH. 2000-01-10 MORIOKA Tomohiko * emh-comp.el (emh-insert-message): Comment out GNUS and Gnus related codes. (emh-yank-cur-msg-with-no-filter): Comment out. * emh.el (emh-raw-buffer): New inline function. (mh-display-msg): Use `emh-raw-buffer'. (emh-toggle-decoding-mode): Likewise. 2000-01-10 MORIOKA Tomohiko * emh.el (emh-toggle-decoding-mode): Don't refer `mime-raw-buffer'. 2000-01-05 Katsumi Yamaoka * Makefile, README.en: Update for the new CVS server. 1999-12-13 Katsumi Yamaoka * README.en: Update for the recent ML address and ftp site. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/semi/semi-1.14-for-flim-1.14/ -------------- next part -------------- -- tomo. From yutopia ＠ t3.rim.or.jp Thu Dec 21 11:20:45 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Thu, 21 Dec 2000 11:20:45 +0900 Subject: FLIM 1.14 and SEMI 1.14 Message-ID: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> おおむらです。 FLIM 1.14.0 と SEMI 1.14.0 が出ていますが、私の環境では 落ちるみたいです。 まだバグが残ってるのかなぁ。 具体的には eword-decode-header がないとなりまして、 cmail の起動自体ができなくなりました。 chao-1.14.1 では、この関数を define-obsolete-function-alias で mime-decode-header-in-buffer に割り当ててるみたいなの で、この関数は使ってはいけないということなのでしょうか。 どうにも、flim/eword-decode.el とか、emu/pces-e20.el の読み込みもうまくいってないようで、.emacs でこれら を読んでやらないと起動もできなくなってしまいます。 ちなみに、APEL は 2000.12.21 現在の CVS 先端のものを使っています。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- From yutopia ＠ t3.rim.or.jp Thu Dec 21 11:29:37 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Thu, 21 Dec 2000 11:29:37 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: Yuh Ohmura's message of "Thu, 21 Dec 2000 11:20:45 +0900" <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> Message-ID: <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> おおむらです。 補足です。 In message "[cmail 9514] FLIM 1.14 and SEMI 1.14" on 00/12/21, Yuh Ohmura writes: > 具体的には eword-decode-header がないとなりまして、 > cmail の起動自体ができなくなりました。 Changelog を見ると delete されたとありましたね。 これは tm 時代の関数なのでしょうか？ だとすると、cmail は tm もサポートしているので、 cmail 側で対応しないといけないですね。 > どうにも、flim/eword-decode.el とか、emu/pces-e20.el > の読み込みもうまくいってないようで、.emacs でこれら > を読んでやらないと起動もできなくなってしまいます。 具体的には find-coding-system が未定義というエラーと なりました。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- From watanabe ＠ sigmaitec.co.jp Thu Dec 21 14:31:39 2000 From: watanabe ＠ sigmaitec.co.jp (=?ISO-2022-JP?B?GyRCRU9KVRsoQiA=?= =?ISO-2022-JP?B?GyRCQDUbKEI=?= / Tadashi Watanabe) Date: 21 Dec 2000 14:31:39 +0900 Subject: verify at GnuPG 1.0.4c Message-ID: 渡辺と申します。 GnuPG 1.0.4c で、 * WARNING: The semantics of --verify have changed to address a problem with detached signature detection. --verify now ignores signed material given on stdin unless this is requested by using a "-" as the name for the file with the signed material. ! Please check all your detached signature handling applications ! ! and make sure that they don't pipe the signed material to stdin ! ! without using a filename and "-" on the the command line. ! という変更があったため、verify に失敗します。 --- pgg-gpg.el.orig Thu Dec 21 13:48:04 2000 +++ pgg-gpg.el Thu Dec 21 13:54:08 2000 @@ -186,6 +186,7 @@ (let ((args '("--batch" "--verify"))) (when (stringp signature) (setq args (append args (list signature)))) + (setq args (append args '("-"))) (pgg-gpg-process-region start end nil pgg-gpg-program args) (with-current-buffer pgg-errors-buffer (goto-char (point-min)) -- 渡辺 正 / Tadashi Watanabe From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 21 16:30:18 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 21 Dec 2000 16:30:18 +0900 Subject: FLIM 1.14 and SEMI 1.14 In-Reply-To: Yuh Ohmura's message of "Thu, 21 Dec 2000 11:20:45 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> [emacs-mime-ja : No.00737] にて >>>>> “大村さん”= Yuh Ohmura さま曰く: 大村さん> FLIM 1.14.0 と SEMI 1.14.0 が出ていますが、私の環境では 大村さん> 落ちるみたいです。 大村さん> まだバグが残ってるのかなぁ。 大村さん> 具体的には eword-decode-header がないとなりまして、 大村さん> cmail の起動自体ができなくなりました。 大村さん> chao-1.14.1 では、この関数を define-obsolete-function-alias 大村さん> で mime-decode-header-in-buffer に割り当ててるみたいなの 大村さん> で、この関数は使ってはいけないということなのでしょうか。 poe 依存性除去の関係から、define-obsolete-function-alias が使えなくなっ たので、そのせいでめんどくさくなってつい eword-decode-header への obsolete alias を comment out してしまったんですが、まだ必要でしょうか？ もし、必要なら flim-1_14 枝に新たに作った FLIM-API.en に [Function] eword-decode-header (&optional code-conversion separator) As same as `mime-decode-header-in-buffer', q.v. [Optional] (Usage: cmail 2.61) みたいに追加します（あるいは、commiter の方、追加してください）。他に も MUA や SEMI 実装等で使ってて、FLIM-API.en に載ってない機能があれば 追加してください。用例 (usage) の追加や形式に関する御意見もお願いしま す。 大村さん> どうにも、flim/eword-decode.el とか、emu/pces-e20.el 大村さん> の読み込みもうまくいってないようで、.emacs でこれら 大村さん> を読んでやらないと起動もできなくなってしまいます。 eword-decode に pces 依存部分があるとしたら bug ですので、できれば pces がない状態での backtrace をお知らせください。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 21 16:46:58 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 21 Dec 2000 16:46:58 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: Yuh Ohmura's message of "Thu, 21 Dec 2000 11:29:37 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> [emacs-mime-ja : No.00738] にて >>>>> “大村さん”= Yuh Ohmura さま曰く: 大村さん> In message "[cmail 9514] FLIM 1.14 and SEMI 1.14" 大村さん> on 00/12/21, Yuh Ohmura writes: 大村さん> > 具体的には eword-decode-header がないとなりまして、 大村さん> > cmail の起動自体ができなくなりました。 大村さん> Changelog を見ると delete されたとありましたね。 大村さん> これは tm 時代の関数なのでしょうか？ 大村さん> だとすると、cmail は tm もサポートしているので、 大村さん> cmail 側で対応しないといけないですね。 SEMI 0.72 (1997-03-14) で登場した関数のようです。 ちなみに、tm 7.106 (1997-03-22) では eword-decode.el ではなく tm-ew-d.el で、関数名は mime/decode-message-header でした。 <昔話> 確か、この前年の冬ぐらいから RMS から tm の GNU Emacs 収録の話が来て、 このための code の整理とか mime/* prefix style を普通の style に直すと か、emu 依存性を除去することを目的に ``September Doctrine''を合言葉に SEMI の開発がはじまったんだったと思います。（思えば、３年以上もずるず ると同じようなことを思い出したようにしてるような気が…(^_^;;;） で、emu 解消のために GNU Emacs と XEmacs の Mule API の統一運動なんて のもしてたような気がするけど、あまりむくわれず、かえって、GNU Emacs 20.3 以降での大変動のあおりで、気が付くと emu (poe) 関連が肥大化してた というか…。 大村さん> > どうにも、flim/eword-decode.el とか、emu/pces-e20.el 大村さん> > の読み込みもうまくいってないようで、.emacs でこれら 大村さん> > を読んでやらないと起動もできなくなってしまいます。 大村さん> 具体的には find-coding-system が未定義というエラーと 大村さん> なりました。 FLIM 1.14 の source tree の中では find-coding-system を見付けることが できませんでした。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 21 17:07:40 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 21 Dec 2000 17:07:40 +0900 Subject: [Emacs20, 21] !! Symbol's function definition is void ((find-coding-system)) In-Reply-To: Keiichi Suzuki's message of "21 Dec 2000 11:06:05 +0900" References: <20001221zohqsg9w.kose@wizard.tamra.co.jp> Message-ID: >>>>> In [apel-ja : No.00475] >>>>> "圭一さん" = Keiichi Suzuki wrote: kose> CVS apel の先端のもので、flim-1_14 をインストールしょうとす kose> るとエラーになりました。 kose> While compiling toplevel forms in file /home/kose/Emacs/elisp/CVS/flim-1_14/mailcap.el: kose> !! Symbol's function definition is void ((find-coding-system)) 圭一さん> 動作上は問題ないと思いますが、うるさすぎますね。 圭一さん> (require 'poem) しないのには何かわけがあるのでしょうか? mcharset は APEL の分類的には emu に属しますが、MIME 関連 module とし て GNU Emacs 21 に附属させることを計画しています。できるだけ差異を少な くしたいので、できるだけ、poe 関連 module を require しないように変え てしまったんですが、良く考えると、APEL の mcharset そのままを使ってい る訳でもないですし、これは失敗でした。すみません。 なお、(require 'poem) じゃなくて (require 'pces) が良いと思います。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 21 17:19:17 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 21 Dec 2000 17:19:17 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: tomo@kanji.zinbun.kyoto-u.ac.jp's message of "21 Dec 2000 16:46:58 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> [emacs-mime-ja : No.00741] にて >>>>> “守岡”= tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) 曰く: 大村さん> > どうにも、flim/eword-decode.el とか、emu/pces-e20.el 大村さん> > の読み込みもうまくいってないようで、.emacs でこれら 大村さん> > を読んでやらないと起動もできなくなってしまいます。 大村さん> 具体的には find-coding-system が未定義というエラーと 大村さん> なりました。 守岡> FLIM 1.14 の source tree の中では find-coding-system を見付ける 守岡> ことができませんでした。 APEL-ja で話題になっていたように、APEL の mcharset.el の不具合だったよ うです。修正してみたつもりなので、よろしければ CVS 上の最新版をお試し ください。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yutopia ＠ t3.rim.or.jp Thu Dec 21 17:11:46 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Thu, 21 Dec 2000 17:11:46 +0900 Subject: [cmail 9518] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "21 Dec 2000 16:46:58 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: <9132-Thu21Dec2000171146+0900-yutopia@t3.rim.or.jp> おおむらです。 In message "[cmail 9518] Re: FLIM 1.14 and SEMI 1.14" on 00/12/21, 守岡 知彦 / MORIOKA Tomohiko writes: > >>>>> [emacs-mime-ja : No.00738] にて > >>>>> “大村さん”= Yuh Ohmura さま曰く: > > 大村さん> Changelog を見ると delete されたとありましたね。 > 大村さん> これは tm 時代の関数なのでしょうか？ > 大村さん> だとすると、cmail は tm もサポートしているので、 > 大村さん> cmail 側で対応しないといけないですね。 > > SEMI 0.72 (1997-03-14) で登場した関数のようです。 > > ちなみに、tm 7.106 (1997-03-22) では eword-decode.el ではなく > tm-ew-d.el で、関数名は mime/decode-message-header でした。 cmail のコードを見たら、まさしく、件の関数をこの tm の関数 と関連付けてました。 > <昔話> > 確か、この前年の冬ぐらいから RMS から tm の GNU Emacs 収録の話が来て、 > このための code の整理とか mime/* prefix style を普通の style に直すと > か、emu 依存性を除去することを目的に ``September Doctrine''を合言葉に > SEMI の開発がはじまったんだったと思います。（思えば、３年以上もずるず > ると同じようなことを思い出したようにしてるような気が…(^_^;;;） はあ。FLIM/SEMI は Emacs に収録すべく活動していたという わけなんですね。 > > 大村さん> 具体的には find-coding-system が未定義というエラーと > 大村さん> なりました。 > > FLIM 1.14 の source tree の中では find-coding-system を見付けることが > できませんでした。 emu/pces-e20.el で defsubst-maybe してました。 FLIM/SEMI のコンパイル中にも件の関数が void であるとおこられてる ようです。 # emu がみつけられてないのかなぁ。 とりあえず、eword-decode-header のコメントをはずして、それから emu/pces-e20.el をむりやり読み込むようにしましたが、まだ うまく動作してくれないようです。 どうも 1.14 系列と cmail の相性はあまりよくないようです。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- From yutopia ＠ t3.rim.or.jp Thu Dec 21 17:40:22 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Thu, 21 Dec 2000 17:40:22 +0900 Subject: [cmail 9520] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "21 Dec 2000 17:19:17 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> おおむらです。 なんか ML の数がだんだん増えていく… # どつぼにもはまっていく…… In message "[cmail 9520] Re: FLIM 1.14 and SEMI 1.14" on 00/12/21, 守岡 知彦 / MORIOKA Tomohiko writes: > >>>>> [emacs-mime-ja : No.00741] にて > >>>>> “守岡”= tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA > Tomohiko) 曰く: > > 大村さん> > どうにも、flim/eword-decode.el とか、emu/pces-e20.el > 大村さん> > の読み込みもうまくいってないようで、.emacs でこれら > 大村さん> > を読んでやらないと起動もできなくなってしまいます。 > > 大村さん> 具体的には find-coding-system が未定義というエラーと > 大村さん> なりました。 > > 守岡> FLIM 1.14 の source tree の中では find-coding-system を見付ける > 守岡> ことができませんでした。 > > APEL-ja で話題になっていたように、APEL の mcharset.el の不具合だったよ > うです。修正してみたつもりなので、よろしければ CVS 上の最新版をお試し > ください。 情報ありがとうございます。 flim/eword-decode.el の eword-decode-header のコメントをはずし、 APEL を最新にすることで、とりあえず、メールの送信はできるように なりました。 ただ、メールを読む段階でまだエラーが出るようです。 mime- ではじまってるので、FLIM 関連かなと思うのですが。 # 単純にコメントをはずしたのがまずかったでしょうか。 backtrace を添付します。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: error.txt.gz 型: application/octet-stream サイズ: 2030 バイト 説明: 無し URL: From keiichi ＠ nanap.org Thu Dec 21 17:43:45 2000 From: keiichi ＠ nanap.org (Keiichi Suzuki) Date: 21 Dec 2000 17:43:45 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: (tomo@kanji.zinbun.kyoto-u.ac.jp's message of "21 Dec 2000 17:19:17 +0900") References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> apel-ja の No. 00477 >>>>> Message-Id: で、 >>>>> "守岡" == tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く... 守岡> APEL-ja で話題になっていたように、APEL の mcharset.el の不具合だったよ 守岡> うです。修正してみたつもりなので、よろしければ CVS 上の最新版をお試し 守岡> ください。 Index: mcharset.el =================================================================== RCS file: /cvs/root/apel/mcharset.el,v retrieving revision 1.9 diff -u -r1.9 mcharset.el --- mcharset.el 2000/12/21 08:17:07 1.9 +++ mcharset.el 2000/12/21 08:38:06 @@ -39,7 +39,8 @@ (require 'mcs-ltn1))) (defcustom default-mime-charset-for-write - (if (and (require 'pces) ; for find-coding-system + (if (and (or (fboundp 'find-coding-system) + (require 'pces nil t)) ; for find-coding-system (find-coding-system 'utf-8)) 'utf-8 default-mime-charset) ...位にしないとあまりうれしくないのではないでしょうか? でも、たとえこうしたとしても、 FLIM 等のコンパイル時に、 !! Symbol's function definition is void ((find-coding-system)) が大量に出るのがうれしくありません。 -- 鈴木圭一 / keiichi ＠ nanap.org PGP finger print (DH/DSS) 0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 21 19:03:58 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 21 Dec 2000 19:03:58 +0900 Subject: [cmail 9520] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: Yuh Ohmura's message of "Thu, 21 Dec 2000 17:40:22 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> [emacs-mime-ja : No.00745] にて >>>>> “大村さん”= Yuh Ohmura さま曰く: 大村さん> 情報ありがとうございます。 大村さん> flim/eword-decode.el の eword-decode-header のコメントをはずし、 大村さん> APEL を最新にすることで、とりあえず、メールの送信はできるように 大村さん> なりました。 大村さん> ただ、メールを読む段階でまだエラーが出るようです。 大村さん> mime- ではじまってるので、FLIM 関連かなと思うのですが。 大村さん> # 単純にコメントをはずしたのがまずかったでしょうか。 大村さん> backtrace を添付します。 Signaling: (invalid-function (macro lambda (name) "Return field-presentation-method from NAME. NAME must be `plain', `wide', `summary' or `nov'." (cond ((eq name nil) (\` (or (assq (quote summary) mime-field-decoder-cache) (quote (summary))))) ((and (consp name) (car name) (consp (cdr name)) (symbolp (car (cdr name))) (null (cdr (cdr name)))) (\` (or (assq (\, name) mime-field-decoder-cache) (cons (\, name) nil)))) (t (\` (or (assq (or (\, name) (quote summary)) mime-field-decoder-cache) (cons (or (\, name) (quote summary)) nil))))))) mime-find-field-presentation-method(wide) mime-insert-header-from-buffer(# 1251014 1252266 ("^From \\|^X-cmail\\|^Received:\\|^Return-Path:\\|^Return-Receipt-To:\\|^Message-ID:\\|^Errors-To:\\|^References:\\|^Sender:\\|^Lines:\\|Status:\\|Replied:") ("^Message-I[dD]:")) 直接の error は macro を関数と思って関数適用を行おうとしてはまっている ようですので、なんとなくうまく compile できてない感じですね。ちゃんと 追ってないし、再現実験をしてないので外しているかも知れませんが。 大村さん> [2 error.txt.gz ] >>>>> [emacs-mime-ja : No.00744] にて >>>>> “大村さん”= Yuh Ohmura さま曰く: 大村さん> はあ。FLIM/SEMI は Emacs に収録すべく活動していたという 大村さん> わけなんですね。 もっともすぐにやる気をなくしてたんですけども。 ;; それどころじゃなくなってたというか。(^_^;; 大村さん> どうも 1.14 系列と cmail の相性はあまりよくないようです。 ;; それにしても、release しないと bug は出てこないもんですね。(^_^; ;;; FLIM-Chao じゃ反応なくてしくしくだし。:-) -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 21 19:18:13 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 21 Dec 2000 19:18:13 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: Keiichi Suzuki's message of "21 Dec 2000 17:43:45 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> In [apel-ja : No.00480] >>>>> "圭一さん" = Keiichi Suzuki wrote: 守岡> APEL-ja で話題になっていたように、APEL の mcharset.el の不具合だったよ 守岡> うです。修正してみたつもりなので、よろしければ CVS 上の最新版をお試し 守岡> ください。 圭一さん> Index: mcharset.el 圭一さん> =================================================================== 圭一さん> RCS file: /cvs/root/apel/mcharset.el,v 圭一さん> retrieving revision 1.9 圭一さん> diff -u -r1.9 mcharset.el 圭一さん> --- mcharset.el 2000/12/21 08:17:07 1.9 圭一さん> +++ mcharset.el 2000/12/21 08:38:06 圭一さん> @@ -39,7 +39,8 @@ 圭一さん> (require 'mcs-ltn1))) 圭一さん> (defcustom default-mime-charset-for-write 圭一さん> - (if (and (require 'pces) ; for find-coding-system 圭一さん> + (if (and (or (fboundp 'find-coding-system) 圭一さん> + (require 'pces nil t)) ; for find-coding-system 圭一さん> (find-coding-system 'utf-8)) 圭一さん> 'utf-8 圭一さん> default-mime-charset) 圭一さん> ...位にしないとあまりうれしくないのではないでしょうか? おっしゃる通りではあるんですが、APEL の場合、必ず pces があるはずです ので、(require 'pces nil t) にすることはうれしくないでしょう。XEmacs の場合、若干うれしいかも知れませんが、APEL では実際に誰が find-coding-system を提供してようと、APEL にとって find-coding-system は pces の機能であるという考えもあるでしょうから、pces を使うと割り切 るなら (fboundp 'find-coding-system) は余計であるという考えもあるでしょ う。 圭一さん> でも、たとえこうしたとしても、 FLIM 等のコンパイル時に、 圭一さん> !! Symbol's function definition is void ((find-coding-system)) 圭一さん> が大量に出るのがうれしくありません。 実は、私が現在使っている Debian (woody) の GNU Emacs 20.7 で上記の現象 を再現できないのです。 皆さんの GNU Emacs 20.7 でも起こっているんでしょうか？ もし起こるとしたらどういう条件にすれば良いんでしょうか？ -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From Makoto.Nakagawa ＠ jp.compaq.com Thu Dec 21 21:49:50 2000 From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?= =?ISO-2022-JP?B?GyRCQD8bKEI=?=) Date: Thu, 21 Dec 2000 21:49:50 +0900 Subject: [cmail 9524] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "21 Dec 2000 19:03:58 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> Message-ID: <1191-Thu21Dec2000214950+0900-Makoto.Nakagawa@jp.compaq.com> 中川＠コンパック(株)です。 In message "[cmail 9524] Re: FLIM 1.14 and SEMI 1.14" on 00/12/21, 守岡 知彦 / MORIOKA Tomohiko wrote: > 直接の error は macro を関数と思って関数適用を行おうとしてはまっている > ようですので、なんとなくうまく compile できてない感じですね。ちゃんと > 追ってないし、再現実験をしてないので外しているかも知れませんが。 ftp.jpl.org から取ってきたものを試してみましたが、同じ現象になりました。 単純に make するだけでは eword-decode.el がコンパイルされませんが、何か 関係ありますでしょうか。試しに mmgeneric.elc を削除したところ、この error は出なくなりました。 -------------- next part -------------- -- /*** Compaq Computer K.K. ***/ /*** Manufacturing Industry Practice/Professional Service ***/ /*** Nakagawa, Makoto（中川　誠） ***/ /*** 0B33 EAC3 F2F6 3D10 D9E9 AE7F 8EDA 44F9 1D29 D44A ***/ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/pgp-signature サイズ: 232 バイト 説明: 無し URL: From ueno ＠ bug.org Thu Dec 21 23:27:17 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 21 Dec 2000 23:27:17 +0900 Subject: verify at GnuPG 1.0.4c In-Reply-To: (=?ISO-2022-JP?B?GyRCRU9KVRsoQiAbJEJANRsoQg==?= / Tadashi Watanabe's message of "21 Dec 2000 14:31:39 +0900") References: Message-ID: <87lmt9n92y.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00739] >>>>> watanabe ＠ sigmaitec.co.jp (渡辺 正 / Tadashi Watanabe) wrote: > GnuPG 1.0.4c で、 > * WARNING: The semantics of --verify have changed to address a problem > with detached signature detection. --verify now ignores signed material > given on stdin unless this is requested by using a "-" as the name for > the file with the signed material. > ! Please check all your detached signature handling applications ! > ! and make sure that they don't pipe the signed material to stdin ! > ! without using a filename and "-" on the the command line. ! > という変更があったため、verify に失敗します。 > --- pgg-gpg.el.orig Thu Dec 21 13:48:04 2000 > +++ pgg-gpg.el Thu Dec 21 13:54:08 2000 ありがとうございます。 取り急ぎ、emiko-1_14 枝にて修正を行いました。 ;; ChangeLog は適当に書いてしまいましたが、何か不具合がありましたら、 ;; お知らせ下さい。 -- Daiki Ueno From ueno ＠ bug.org Thu Dec 21 23:38:39 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 21 Dec 2000 23:38:39 +0900 Subject: binary-start-process Message-ID: <87hf3xn8k0.fsf@gg.bug.org> 上野です。 2000-12-16 MORIOKA Tomohiko * pgg-gpg.el (pgg-gpg-process-region): Use `binary-start-process'. の変更の意図は何でしょう？ as-binary-process ではなく as-binary-output-file を使ったのは、 http://lists.airs.net/wl/archive/200008/msg00020.html という背景があるからなのですが、binary-start-process を使ってしまうと、 いかに language-info-alist を指定しようと、modify-coding-system-alist で 頑張ろうと、絶対に GnuPG の日本語メッセージを扱える筈はないと思うのですが。 ;; とりあえず、これが必要かどうかはわかりませんが、御要望にお答えして、 ;; pgg-messages-coding-system 及び、pgg-gpg-messages-coding-system を ;; 新設しました。 -- Daiki Ueno From yutopia ＠ t3.rim.or.jp Fri Dec 22 09:34:51 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Fri, 22 Dec 2000 09:34:51 +0900 Subject: [cmail 9525] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: =?ISO-2022-JP?B?GyRCQ2ZAbhsoQiAbJEJAPxsoQidz?= message of "Thu, 21 Dec 2000 21:49:50 +0900"<1191-Thu21Dec2000214950+0900-Makoto.Nakagawa@jp.compaq.com> References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> <1191-Thu21Dec2000214950+0900-Makoto.Nakagawa@jp.compaq.com> Message-ID: <638-Fri22Dec2000093451+0900-yutopia@t3.rim.or.jp> おおむらです。 In message "[cmail 9525] Re: FLIM 1.14 and SEMI 1.14" on 00/12/21, 中川 誠 writes: > In message "[cmail 9524] Re: FLIM 1.14 and SEMI 1.14" > on 00/12/21, 守岡 知彦 / MORIOKA Tomohiko wrote: > > > 直接の error は macro を関数と思って関数適用を行おうとしてはまっている > > ようですので、なんとなくうまく compile できてない感じですね。ちゃんと > > 追ってないし、再現実験をしてないので外しているかも知れませんが。 > > ftp.jpl.org から取ってきたものを試してみましたが、同じ現象になりました。 > > 単純に make するだけでは eword-decode.el がコンパイルされませんが、何か > 関係ありますでしょうか。試しに mmgeneric.elc を削除したところ、この > error は出なくなりました。 当方でも確認したところ、同じ現象でした。 バイトコンパイルに失敗しているファイルが結構あるみたいです。 mmgeneric.elc の削除で error はなくなります。 バイトコンパイルの結果からすると、find-coding-system がみつ からないのが原因のようです。 # でも flim のモジュールからは直接呼ばれてないはずなんです # よねぇ。 find-coding-system は emu で定義されてるようでもあるのですが。 # apel-ja を CC に再度追加しました。 コンパイルログを添付します。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- 504 /temp/flim-1.14.0 > make emacs -batch -q -no-site-file -l FLIM-MK -f compile-flim NONE NONE \ NONE Loading d:/temp/flim-1.14.0/FLIM-CFG... Loading d:/temp/flim-1.14.0/FLIM-ELS... While compiling toplevel forms in file d:/temp/flim-1.14.0/mailcap.el: !! Symbol's function definition is void ((find-coding-system)) Wrote d:/temp/flim-1.14.0/sha1-el.elc Wrote d:/temp/flim-1.14.0/md5-el.elc Wrote d:/temp/flim-1.14.0/hex-util.elc Wrote d:/temp/flim-1.14.0/hmac-def.elc Wrote d:/temp/flim-1.14.0/md5.elc Wrote d:/temp/flim-1.14.0/sha1.elc While compiling toplevel forms in file d:/temp/flim-1.14.0/hmac-md5.el: ** md5 called with 4 arguments, but accepts only 1-3 ** md5 called with 4 arguments, but accepts only 1-3 ** the function md5-binary is not known to be defined. Wrote d:/temp/flim-1.14.0/hmac-md5.elc Wrote d:/temp/flim-1.14.0/hmac-sha1.elc While compiling toplevel forms in file d:/temp/flim-1.14.0/mel-b-ccl.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mel-q-ccl.el: !! Symbol's function definition is void ((find-coding-system)) Wrote d:/temp/flim-1.14.0/std11.elc Wrote d:/temp/flim-1.14.0/luna.elc Wrote d:/temp/flim-1.14.0/lunit.elc While compiling toplevel forms in file d:/temp/flim-1.14.0/mime-def.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mel.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mel-q.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mel-u.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mel-g.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/eword-decode.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/eword-encode.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mime.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mime-parse.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mmgeneric.el: ** reference to free variable default-mime-charset ** The following functions are not known to be defined: mime-entity-content, mime-content-type-parameter, mime-entity-content-type, mime-find-field-presentation-method, mime-find-field-decoder-internal Wrote d:/temp/flim-1.14.0/mmgeneric.elc While compiling toplevel forms in file d:/temp/flim-1.14.0/mmbuffer.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mmcooked.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mmexternal.el: !! Symbol's function definition is void ((find-coding-system)) While compiling toplevel forms in file d:/temp/flim-1.14.0/mime-conf.el: !! Symbol's function definition is void ((find-coding-system)) Wrote d:/temp/flim-1.14.0/sasl.elc Wrote d:/temp/flim-1.14.0/sasl-cram.elc Wrote d:/temp/flim-1.14.0/sasl-digest.elc Wrote d:/temp/flim-1.14.0/smtp.elc Wrote d:/temp/flim-1.14.0/qmtp.elc Wrote d:/temp/flim-1.14.0/smtpmail.elc Wrote d:/temp/flim-1.14.0/raw-io.elc PREFIX=d:/USR LISPDIR=d:/USR/MEADOW/1.10/site-lisp From yutopia ＠ t3.rim.or.jp Fri Dec 22 10:19:10 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Fri, 22 Dec 2000 10:19:10 +0900 Subject: [cmail 9526] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: Yuh Ohmura's message of "Fri, 22 Dec 2000 09:34:51 +0900" <638-Fri22Dec2000093451+0900-yutopia@t3.rim.or.jp> References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> <1191-Thu21Dec2000214950+0900-Makoto.Nakagawa@jp.compaq.com> <638-Fri22Dec2000093451+0900-yutopia@t3.rim.or.jp> Message-ID: <4488-Fri22Dec2000101910+0900-yutopia@t3.rim.or.jp> おおむらです。 In message "[cmail 9526] Re: FLIM 1.14 and SEMI 1.14" on 00/12/22, Yuh Ohmura writes: > バイトコンパイルの結果からすると、find-coding-system がみつ > からないのが原因のようです。 > # でも flim のモジュールからは直接呼ばれてないはずなんです > # よねぇ。 ちなみに、nana-gnus-7.1.0.24 でも、 > !! Symbol's function definition is void ((find-coding-system)) が出てコンパイルできないモジュールが多いみたいです。 In message "[cmail 9524] Re: FLIM 1.14 and SEMI 1.14" on 00/12/21, 守岡 知彦 / MORIOKA Tomohiko writes: > >>>>> [emacs-mime-ja : No.00744] にて > >>>>> “大村さん”= Yuh Ohmura さま曰く: > > 大村さん> はあ。FLIM/SEMI は Emacs に収録すべく活動していたという > 大村さん> わけなんですね。 > > もっともすぐにやる気をなくしてたんですけども。 > > ;; それどころじゃなくなってたというか。(^_^;; それで、Emacs 21 は独自の mime を持ってると。 > 大村さん> どうも 1.14 系列と cmail の相性はあまりよくないようです。 > > ;; それにしても、release しないと bug は出てこないもんですね。(^_^; > > ;;; FLIM-Chao じゃ反応なくてしくしくだし。:-) Chao では問題なかったんですけどねぇ。 Flim-Chao は使わなかったもので。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- From yutopia ＠ t3.rim.or.jp Fri Dec 22 10:35:12 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Fri, 22 Dec 2000 10:35:12 +0900 Subject: [cmail 9526] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: Yuh Ohmura's message of "Fri, 22 Dec 2000 09:34:51 +0900" <638-Fri22Dec2000093451+0900-yutopia@t3.rim.or.jp> References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> <1191-Thu21Dec2000214950+0900-Makoto.Nakagawa@jp.compaq.com> <638-Fri22Dec2000093451+0900-yutopia@t3.rim.or.jp> Message-ID: <6404-Fri22Dec2000103512+0900-yutopia@t3.rim.or.jp> おおむらです。 追加情報です。 APEL 10.2 正式リリース版では件のエラーは起きないで、 FLIM の eword-decode.el のコメントをはずすだけで cmail が正常に動作するということです。 --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- From keiichi ＠ nanap.org Fri Dec 22 10:55:19 2000 From: keiichi ＠ nanap.org (Keiichi Suzuki) Date: 22 Dec 2000 10:55:19 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: (tomo@kanji.zinbun.kyoto-u.ac.jp's message of "21 Dec 2000 19:18:13 +0900") References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> 21 Dec 2000 19:18:13 +0900 に、 >>>>> Message-Id: のメイルで、 >>>>> "守岡" == tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く... 圭一> でも、たとえこうしたとしても、 FLIM 等のコンパイル時に、 圭一> !! Symbol's function definition is void ((find-coding-system)) 圭一> が大量に出るのがうれしくありません。 守岡> 実は、私が現在使っている Debian (woody) の GNU Emacs 20.7 で上記の現象 守岡> を再現できないのです。 守岡> 皆さんの GNU Emacs 20.7 でも起こっているんでしょうか？ 守岡> もし起こるとしたらどういう条件にすれば良いんでしょうか？ mcharset.el 内で起こっているのではなくて、 mcs-20.el の 60 行目 の find-coding-system でエラーになっているようです。 それまでの過程で、 pces を require しているところを探したのです が、 mcs-e20.el 内にはあるものの、 eval-when-compile になってい ます。 ;; 守岡さんのところで起こらないのが不思議。 -- 鈴木圭一 / keiichi ＠ nanap.org PGP finger print (DH/DSS) 0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 13:18:17 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 13:18:17 +0900 Subject: binary-start-process In-Reply-To: Daiki Ueno's message of "21 Dec 2000 23:38:39 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00751] >>>>> "Daiki" = Daiki Ueno wrote: Daiki> 2000-12-16 MORIOKA Tomohiko Daiki> * pgg-gpg.el (pgg-gpg-process-region): Use Daiki> `binary-start-process'. Daiki> の変更の意図は何でしょう？ Daiki> as-binary-process ではなく as-binary-output-file を使ったのは、 意図は (a) as-binary-* から binary-* という coding standard にあった形にする こと (b) なるべく macro は避けること (c) なるべく dynamic binding を使った制御は止めること (d) emacsen の process 実装上の trick を用いることは避けること だったのですが、(d) は私の誤解です。虫を入れてしまってすみません。 Daiki> http://lists.airs.net/wl/archive/200008/msg00020.html Daiki> という背景があるからなのですが、binary-start-process を使ってし Daiki> まうと、いかに language-info-alist を指定しようと、 Daiki> modify-coding-system-alist で頑張ろうと、絶対に GnuPG の日本語 Daiki> メッセージを扱える筈はないと思うのですが。 おっしゃる通りです。 Daiki> ;; とりあえず、これが必要かどうかはわかりませんが、御要望にお答 Daiki> ;; えして、pgg-messages-coding-system 及び、 Daiki> ;; pgg-gpg-messages-coding-system を新設しました。 ありがとうございます。 あと、これもしくはそれ以外の手段を使って、命令 `set-language-environment' and/or 変数 `current-language-environment' と同期する形で適切に PGG の表示を設定することは可能でしょうか？ -- 守岡 知彦 (MORIOKA Tomohiko) From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 13:21:33 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 13:21:33 +0900 Subject: [cmail 9520] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: tomo@kanji.zinbun.kyoto-u.ac.jp's message of "21 Dec 2000 19:03:58 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00747] >>>>> "守岡" = tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 大村さん> 情報ありがとうございます。 大村さん> flim/eword-decode.el の eword-decode-header のコメントをはずし、 大村さん> APEL を最新にすることで、とりあえず、メールの送信はできるように 大村さん> なりました。 大村さん> ただ、メールを読む段階でまだエラーが出るようです。 大村さん> mime- ではじまってるので、FLIM 関連かなと思うのですが。 大村さん> # 単純にコメントをはずしたのがまずかったでしょうか。 大村さん> backtrace を添付します。 守岡> Signaling: (invalid-function (macro lambda (name) "Return 守岡> field-presentation-method from NAME. 守岡> NAME must be `plain', `wide', `summary' or `nov'." (cond ((eq name 守岡> nil) (\` (or (assq (quote summary) mime-field-decoder-cache) (quote 守岡> (summary))))) ((and (consp name) (car name) (consp (cdr name)) 守岡> (symbolp (car (cdr name))) (null (cdr (cdr name)))) (\` (or (assq (\, 守岡> name) mime-field-decoder-cache) (cons (\, name) nil)))) (t (\` (or 守岡> (assq (or (\, name) (quote summary)) mime-field-decoder-cache) (cons 守岡> (or (\, name) (quote summary)) nil))))))) 守岡> mime-find-field-presentation-method(wide) 守岡> mime-insert-header-from-buffer(# 守岡> 1251014 1252266 ("^From 守岡> \\|^X-cmail\\|^Received:\\|^Return-Path:\\|^Return-Receipt-To:\\|^Message-ID:\\|^Errors-To:\\|^References:\\|^Sender:\\|^Lines:\\|Status:\\|Replied:") 守岡> ("^Message-I[dD]:")) 守岡> 直接の error は macro を関数と思って関数適用を行おうとしてはまっ 守岡> ているようですので、なんとなくうまく compile できてない感じです 守岡> ね。ちゃんと追ってないし、再現実験をしてないので外しているかも知 守岡> れませんが。 昨晩、Emacs 21 with FLIM/SEMI を make bootstrap した時に上記の問題を再 現することができ、mmgeneric.el を修正しました。 多分、最新の flim-1_14 では直っているのではないかと思います。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 13:29:23 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 13:29:23 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: Keiichi Suzuki's message of "22 Dec 2000 10:55:19 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> In [apel-ja : No.00489] >>>>> "圭一さん" = Keiichi Suzuki wrote: 圭一さん> mcharset.el 内で起こっているのではなくて、 mcs-20.el の 60 圭一さん> 行目の find-coding-system でエラーになっているようです。 圭一さん> それまでの過程で、 pces を require しているところを探したの 圭一さん> ですが、 mcs-e20.el 内にはあるものの、 eval-when-compile に 圭一さん> なっています。 なるほど。 という訳で、mcs-e20.el で (require 'pces) してみました。 圭一さん> ;; 守岡さんのところで起こらないのが不思議。 ;; なんかどっかに怪しげな設定があるのかな？(^_^;;; -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 13:38:53 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 13:38:53 +0900 Subject: FLIM 1.14 and SEMI 1.14 In-Reply-To: tomo@kanji.zinbun.kyoto-u.ac.jp's message of "21 Dec 2000 16:30:18 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> [emacs-mime-ja : No.00740] にて >>>>> “守岡”= tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) 曰く: 大村さん> 具体的には eword-decode-header がないとなりまして、 大村さん> cmail の起動自体ができなくなりました。 大村さん> chao-1.14.1 では、この関数を define-obsolete-function-alias 大村さん> で mime-decode-header-in-buffer に割り当ててるみたいなの 大村さん> で、この関数は使ってはいけないということなのでしょうか。 守岡> poe 依存性除去の関係から、define-obsolete-function-alias が使え 守岡> なくなったので、そのせいでめんどくさくなってつい 守岡> eword-decode-header へのobsolete alias を comment out してしまっ 守岡> たんですが、まだ必要でしょうか？ 守岡> もし、必要なら flim-1_14 枝に新たに作った FLIM-API.en に 守岡> [Function] eword-decode-header (&optional code-conversion separator) 守岡> As same as `mime-decode-header-in-buffer', q.v. 守岡> [Optional] (Usage: cmail 2.61) 守岡> みたいに追加します（あるいは、commiter の方、追加してください）。 守岡> 他にも MUA や SEMI 実装等で使ってて、FLIM-API.en に載ってない機 守岡> 能があれば追加してください。用例 (usage) の追加や形式に関する御 守岡> 意見もお願いします。 という訳で、eword-decode-header を復活させました。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 14:06:02 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 14:06:02 +0900 Subject: binary-start-process In-Reply-To: tomo@kanji.zinbun.kyoto-u.ac.jp's message of "22 Dec 2000 13:18:17 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00756] >>>>> "守岡" = tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> (d) emacsen の process 実装上の trick を用いることは避けること 守岡> だったのですが、(d) は私の誤解です。虫を入れてしまってすみません。 これも事実誤認ですね。実際には pces の実装上の trick を使って、仕様外 の使い方をしてたのが問題だったといえると思います。 いずれにしても、すみませんでした。 Daiki> http://lists.airs.net/wl/archive/200008/msg00020.html Daiki> という背景があるからなのですが、binary-start-process を使ってし Daiki> まうと、いかに language-info-alist を指定しようと、 Daiki> modify-coding-system-alist で頑張ろうと、絶対に GnuPG の日本語 Daiki> メッセージを扱える筈はないと思うのですが。 守岡> おっしゃる通りです。 language-info-alist は何でもありですから、適当な機構を PGG が提供する ことにより、それを使った設定を set-language-environment と同期して行う ことは可能です。 Daiki> ;; とりあえず、これが必要かどうかはわかりませんが、御要望にお答 Daiki> ;; えして、pgg-messages-coding-system 及び、 Daiki> ;; pgg-gpg-messages-coding-system を新設しました。 守岡> ありがとうございます。 すみません。これはどこにあるんでしょうか？現在の公的開発枝である semi-1_14にはないようですが。 あと、私の強い希望は上記を作ることではなく、下記の 守岡> あと、これもしくはそれ以外の手段を使って、命令 守岡> `set-language-environment' and/or 変数 守岡> `current-language-environment' と同期する形で適切に PGG の表示を 守岡> 設定することは可能でしょうか？ ですので、もし、pgg-messages-coding-system や pgg-gpg-messages-coding-system が本質的に不要なものなのだとしたらない 方が良いと思います。 ;; PGG を user interface を備えない module と捉えるなら coding-system ;; や locale に関する設定用界面を設けるだけで、 ;; `set-language-environment' との同期は mime-pgp の責任とする考え方も ;; あると思います。でも、PGG には command があるので、個人的には PGGで ;; （も）`set-language-environment' との同期ができた方が良いと思います ;; が。 -- 守岡 知彦 (MORIOKA Tomohiko) From yutopia ＠ t3.rim.or.jp Fri Dec 22 14:38:06 2000 From: yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Date: Fri, 22 Dec 2000 14:38:06 +0900 Subject: [cmail 9542] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "22 Dec 2000 13:21:33 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> <2102-Thu21Dec2000174022+0900-yutopia@t3.rim.or.jp> Message-ID: <1068-Fri22Dec2000143806+0900-yutopia@t3.rim.or.jp> おおむらです。 In message "[cmail 9542] Re: FLIM 1.14 and SEMI 1.14" on 00/12/22, 守岡 知彦 / MORIOKA Tomohiko writes: > 昨晩、Emacs 21 with FLIM/SEMI を make bootstrap した時に上記の問題を再 > 現することができ、mmgeneric.el を修正しました。 > > 多分、最新の flim-1_14 では直っているのではないかと思います。 In message "[cmail 9544] Re: FLIM 1.14 and SEMI 1.14" on 00/12/22, 守岡 知彦 / MORIOKA Tomohiko writes: > という訳で、eword-decode-header を復活させました。 動作を確認しました。 # 試行錯誤でようやっと CVS ツリーからとってきました ^^;;; --------------- salve! ----------------- mailto:yutopia ＠ t3.rim.or.jp (Yuh Ohmura) Uri: http://www.t3.rim.or.jp/%7Eyutopia/ ---------------------------------------- From ueno ＠ bug.org Fri Dec 22 15:43:21 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 22 Dec 2000 15:43:21 +0900 Subject: binary-start-process In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "22 Dec 2000 14:06:02 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> Message-ID: <87k88tklbq.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00760] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> (d) emacsen の process 実装上の trick を用いることは避けること 守岡> だったのですが、(d) は私の誤解です。虫を入れてしまってすみません。 守岡> これも事実誤認ですね。実際には pces の実装上の trick を使って、仕様外 守岡> の使い方をしてたのが問題だったといえると思います。 守岡> いずれにしても、すみませんでした。 個人的には、例えば、 binary-input-start-process binary-output-start-process binary-input-start-process-shell-command binary-output-start-process-shell-command binary-input-open-network-stream binary-output-open-network-stream のような variant を用意することなく、制御できる枠組があると嬉しいのですが。 守岡> language-info-alist は何でもありですから、適当な機構を PGG が提供する 守岡> ことにより、それを使った設定を set-language-environment と同期して行う 守岡> ことは可能です。 これは必要なのでしょうか？ coding-system-for-read を束縛せずに start-process を呼んだときに、Emacs の automatic conversion がうまくいかない言語環境が存在する、ということ でしょうか？ 守岡> すみません。これはどこにあるんでしょうか？現在の公的開発枝である 守岡> semi-1_14にはないようですが。 emiko-1_14 にあります。 守岡> あと、私の強い希望は上記を作ることではなく、下記の 守岡> あと、これもしくはそれ以外の手段を使って、命令 守岡> `set-language-environment' and/or 変数 守岡> `current-language-environment' と同期する形で適切に PGG の表示を 守岡> 設定することは可能でしょうか？ 「current-language-environment と同期する形で PGG の表示を設定する」とは、 $ LANG=C emacs M-x set-language-environment Japanese としたときに、依然 process-environment には LANG=C が含まれたまま gpg が 呼ばれてしまうので、これを制御する、ということでしょうか？ そうであるとすると、pgg-messages-locale を新設し、 (set|get)-language-info によりこれを制御すれば良いのではないかと思います。 ;; しかしながら、この場合、override すべき LC_MESSAGES には単に "ja" のよう ;; な言語コードを設定するだけで良いのでしょうか。また、Emacs21 では ;; system-messsages-locale が用意されていますが、set-language-environment ;; しただけでは、system-messages-locale は設定されません。これは何を意味 ;; するのでしょうか？ 守岡> ;; PGG を user interface を備えない module と捉えるなら coding-system 守岡> ;; や locale に関する設定用界面を設けるだけで、 守岡> ;; `set-language-environment' との同期は mime-pgp の責任とする考え方も 守岡> ;; あると思います。でも、PGG には command があるので、個人的には PGGで 守岡> ;; （も）`set-language-environment' との同期ができた方が良いと思います 守岡> ;; が。 基本的に、PGG は SEMI の一部でしかないので、この際、界面を整理して command 群を撤廃するというのも良いのではないかと思います。 -- Daiki Ueno From Taiji.Can ＠ atesoft.advantest.co.jp Fri Dec 22 16:29:16 2000 From: Taiji.Can ＠ atesoft.advantest.co.jp (Taiji.Can ＠ atesoft.advantest.co.jp) Date: Fri, 22 Dec 2000 16:29:16 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: 菅です。 > APEL-ja で話題になっていたように、APEL の mcharset.el の不具合だったよ > うです。修正してみたつもりなので、よろしければ CVS 上の最新版をお試し > ください。 apel の mcharset.el なんですが、このように変更されてしまうと、 nemacs では find-coding-system が pces-nemacs.el には存在しないので、 初っ端で tm のコンパイルが失敗してしまいます。 -- ADVANTEST corp. Taiji.Can ＠ atesoft.advantest.co.jp From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 17:12:11 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 17:12:11 +0900 Subject: binary-start-process In-Reply-To: Daiki Ueno's message of "22 Dec 2000 15:43:21 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00762] >>>>> "Daiki" = Daiki Ueno wrote: 守岡> (d) emacsen の process 実装上の trick を用いることは避けること 守岡> だったのですが、(d) は私の誤解です。虫を入れてしまってすみません。 守岡> これも事実誤認ですね。実際には pces の実装上の trick を使って、 守岡> 仕様外の使い方をしてたのが問題だったといえると思います。 守岡> いずれにしても、すみませんでした。 Daiki> 個人的には、例えば、 Daiki> binary-input-start-process Daiki> binary-output-start-process Daiki> binary-input-start-process-shell-command Daiki> binary-output-start-process-shell-command Daiki> binary-input-open-network-stream Daiki> binary-output-open-network-stream Daiki> のような variant を用意することなく、制御できる枠組があると嬉し Daiki> いのですが。 全く持って同感です。 個人的には、将来、型付き stream と多層 chunk object model に基づく、入 出力、および、データ表現に関する抽象を実現し、file, process, network, buffer, region, 文字列、vector 等を透過的に扱えるようにするのは、是非、 取り組みたいテーマの１つです。 でも、それは今回の FLIM/SEMI project の課題ではなくて、UTF-2000 project（ないしは、その後継 project）の課題だと思っています。そういう 訳で、是非 UTF-2000 project でも活発に御参加頂けたら幸いです。 とりあえず、macro は良くないと思うし、coding-system-for-{read|write} を囲むというのも特定の Mule 実装の構成法に依存するので、良くない方法だ と思います。 （少なくとも私にとっての）FLIM では、byte 列と文字列は違う抽象型です。 文字列とは違う型のものを入出力するなら、文字列用の入出力とは違うことを 明示するのが良いと思います。しかし、今の Mule API には汎用の入出力機構 はなく（私と半田さんらで、個人的には、将来構想として議論していますが）、 いわば文字列と coding-system や、unibyte/multibyte, その他 ad-hoc な方 法でごまかしているのが現状です。とはいえ、データ抽象を愛するものとして は、byte 列と文字列は違うことを弁え、できるだけそれを明示すべく記述す るのが良いと思います。 また、敢えて、binary-* のような専用の関数を設けることの利点を述べるな ら、将来、入出力での変換の制御のためのより良い汎用の機構ができた時にも 容易に実装できそうだという可能性が高そうだということもあると思います。 let で囲む方法ではこの点が困難だと思います。まあ、そんな将来のことなん て知ったことではないとは思いますが。 守岡> language-info-alist は何でもありですから、適当な機構を PGG が提 守岡> 供することにより、それを使った設定を set-language-environment と 守岡> 同期して行うことは可能です。 Daiki> これは必要なのでしょうか？ 判りませんが、やろうと思ったらかなり何でもできるということを言っている だけです。 Daiki> coding-system-for-read を束縛せずに start-process を呼んだとき Daiki> に、Emacsの automatic conversion がうまくいかない言語環境が存在 Daiki> する、ということでしょうか？ 守岡> すみません。これはどこにあるんでしょうか？現在の公的開発枝である 守岡> semi-1_14にはないようですが。 Daiki> emiko-1_14 にあります。 了解しました。 守岡> あと、私の強い希望は上記を作ることではなく、下記の 守岡> あと、これもしくはそれ以外の手段を使って、命令 守岡> `set-language-environment' and/or 変数 守岡> `current-language-environment' と同期する形で適切に PGG の表示を 守岡> 設定することは可能でしょうか？ Daiki> 「current-language-environment と同期する形で PGG の表示を設定 Daiki> する」とは、 Daiki> $ LANG=C emacs Daiki> M-x set-language-environment Japanese Daiki> としたときに、依然 process-environment には LANG=C が含まれたま Daiki> ま gpg が呼ばれてしまうので、これを制御する、ということでしょう Daiki> か？ はい。できればそうした方が良いでしょうね。 Daiki> そうであるとすると、pgg-messages-locale を新設し、 Daiki> (set|get)-language-info によりこれを制御すれば良いのではないか Daiki> と思います。 良いんじゃないかと思います。 Daiki> ;; しかしながら、この場合、override すべき LC_MESSAGES には単に Daiki> ;; "ja" のような言語コードを設定するだけで良いのでしょうか。ま Daiki> ;; た、Emacs21 ではsystem-messsages-locale が用意されていますが、 Daiki> ;; set-language-environmentしただけでは、system-messages-locale Daiki> ;; は設定されません。これは何を意味するのでしょうか？ 良くは把握してないのですが、原理的に考えれば、言語というのは nest する と思うので、大本の emacs 全体の locale が必要なのは当然だと思います。 これにかぶさる形で、buffer の言語があり、buffer 内の文書の中でまた別の 言語の文や単語を引用してたり含んでたりするというような階層構造になると 思います。 ;; ただ、現在の Emacs 21 ないしは Mule 実装を根拠にするのは甚だ危うい ;; と思います。ご存知のように Emacs は絶えず普請中ですし、Mule のだめ ;; さは Mule project の member 自身が認めているでしょう（というか、 ;; Mule の最大の批判者かも）。特に、language-environment 関連がでたら ;; めなのは project leader も常に問題視しており、font の整備と同時に早 ;; 急に何とかしたいテーマの一つとして考えられているようです。 そういう訳で、XEmacs-mule の中途半端な国際化と同様、整合性のある体系と しての意味はないと思います。 守岡> ;; PGG を user interface を備えない module と捉えるなら 守岡> ;; coding-systemや locale に関する設定用界面を設けるだけで、 守岡> ;; `set-language-environment' との同期は mime-pgp の責任とする考 守岡> ;; え方もあると思います。でも、PGG には command があるので、個人 守岡> ;; 的には PGGで（も）`set-language-environment' との同期ができた 守岡> ;; 方が良いと思いますが。 Daiki> 基本的に、PGG は SEMI の一部でしかないので、この際、界面を整理 Daiki> して command 群を撤廃するというのも良いのではないかと思います。 それも１つの方向だと思います。 -- 守岡 知彦 (MORIOKA Tomohiko) From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 18:53:23 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 18:53:23 +0900 Subject: FLIM 1.14.1 =?ISO-2022-JP?B?KBskQkgsTFobKEIp?= Message-ID: [Status] alpha [Recommended environment] APEL: 10.2 (or latest CVS snapshot) [Changes] 2000-12-22 MORIOKA Tomohiko * FLIM: Version 1.14.1 (Yagi) released. 2000-12-22 Keiichi Suzuki * mel-q.el: Require `poem' for `string-to-char-list' when compiling. 2000-12-22 MORIOKA Tomohiko * eword-decode.el (eword-decode-header): Revert to obsolete alias. 2000-12-22 MORIOKA Tomohiko * mmgeneric.el: Add comment for eword-decode. 2000-12-21 MORIOKA Tomohiko * mailcap.el: Require `poe' for `define-obsolete-function-alias'. 2000-12-21 Daiki Ueno * smtp.el (smtp-send-buffer): Add DOC. (smtp-via-smtp): Add DOC. * FLIM-API.en (QMTP): Remove section. (smtp-send-buffer): Add description. (smtp-via-smtp): Likewise. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/flim/flim-1.14/ -------------- next part -------------- -- tomo. From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Fri Dec 22 20:22:59 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 22 Dec 2000 20:22:59 +0900 Subject: SEMI 1.14.1 =?ISO-2022-JP?B?KBskQjJDMmwyOUB0GyhCKQ==?= Message-ID: [Status] alpha [Required Environment] APEL: 9.22 (or later) FLIM: 1.14.1 [Changes] 2000-12-22 MORIOKA Tomohiko * SEMI: Version 1.14.1 (Kaga-Onsen) released. * README.en (Required environment): Require FLIM 1.14.1 or later; update required emacsen. 2000-12-22 MORIOKA Tomohiko * pgg-gpg.el (pgg-gpg-process-region): Use `pgg-gpg-messages-coding-system'. 2000-12-21 Tadashi Watanabe * pgg-gpg.el (pgg-scheme-verify-region): Use a "-" as the name for the file with the signed material. 2000-12-21 Daiki Ueno * pgg-def.el (pgg-messages-coding-system): New user option. 2000-12-20 MORIOKA Tomohiko * mime-view.el: Don't use `static-cond'. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/semi/semi-1.14-for-flim-1.14/ -------------- next part -------------- -- tomo. From yamaoka ＠ jpl.org Fri Dec 22 20:56:54 2000 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 22 Dec 2000 20:56:54 +0900 Subject: CLIME 1.14 References: <87r93921os.fsf@gg.bug.org> <283dfm2opl.wl@jpl.org> Message-ID: その後の clime-1_14 ですが、最新の flime-1_14 への synch とともに、 SEMI 1.14 と組み合わせて上位の Emacsen でも使えるようにしてあります。 ただ Nemacs を含めたすべての Emacsen で完全な動作検証はしていませんの で、みなさまのご協力が必要です。どうぞよろしくお願いいたします。 ;; 別の場所にも書きましたが、もしかしたらぼくは今日で御用納めになるか ;; もしれません。とりあえず みなさま、良いお年をお迎え下さい。:-) -- Katsumi Yamaoka From ueno ＠ bug.org Fri Dec 22 21:31:55 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 22 Dec 2000 21:31:55 +0900 Subject: binary-start-process In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "22 Dec 2000 17:12:11 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> Message-ID: <87lmt8y6v8.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00764] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> また、敢えて、binary-* のような専用の関数を設けることの利点を述べ 守岡> るなら、将来、入出力での変換の制御のためのより良い汎用の機構ができ 守岡> た時にも容易に実装できそうだという可能性が高そうだということもある 守岡> と思います。let で囲む方法ではこの点が困難だと思います。まあ、そん 守岡> な将来のことなんて知ったことではないとは思いますが。 ううむ。個人的にはまったく逆の立場で、dynamic binding のほうがまだ、 移行は簡単ではないかという感想を抱いているのですが、専用の関数を設けるこ とで移行の手間が減少する例を挙げて頂けないでしょうか。 守岡> language-info-alist は何でもありですから、適当な機構を PGG が提 守岡> 供することにより、それを使った設定を set-language-environment と 守岡> 同期して行うことは可能です。 Daiki> これは必要なのでしょうか？ 守岡> 判りませんが、やろうと思ったらかなり何でもできるということを言って 守岡> いるだけです。 何でもできるのでしたら、PGG の場合の、守岡さんの提唱する界面における、 言語環境の設定を見せて頂けませんか？ ;; 不完全なものでも構いません。 こちらは、是非お願いします。 Daiki> ;; しかしながら、この場合、override すべき LC_MESSAGES には単に Daiki> ;; "ja" のような言語コードを設定するだけで良いのでしょうか。ま Daiki> ;; た、Emacs21 ではsystem-messsages-locale が用意されていますが、 Daiki> ;; set-language-environmentしただけでは、system-messages-locale Daiki> ;; は設定されません。これは何を意味するのでしょうか？ 守岡> 良くは把握してないのですが、原理的に考えれば、言語というのは nest 守岡> すると思うので、大本の emacs 全体の locale が必要なのは当然だと思 守岡> います。これにかぶさる形で、buffer の言語があり、buffer 内の文書の 守岡> 中でまた別の言語の文や単語を引用してたり含んでたりするというような 守岡> 階層構造になると思います。 守岡> ;; ただ、現在の Emacs 21 ないしは Mule 実装を根拠にするのは甚だ危うい 守岡> ;; と思います。ご存知のように Emacs は絶えず普請中ですし、Mule のだめ 守岡> ;; さは Mule project の member 自身が認めているでしょう（というか、 守岡> ;; Mule の最大の批判者かも）。特に、language-environment 関連がでたら 守岡> ;; めなのは project leader も常に問題視しており、font の整備と同時に早 守岡> ;; 急に何とかしたいテーマの一つとして考えられているようです。 守岡> そういう訳で、XEmacs-mule の中途半端な国際化と同様、整合性のある体系と 守岡> しての意味はないと思います。 ここで Emacs 21 の例を出したのは、Emacs 21 の実装を基準とするというよりも、 むしろ、XEmacs の auto-language-alist を見ればわかるように、locale name と言語環境の対応付けが 1:1 ではないために、Emacs 21 はあえて言語環境の変 化に system-messages-locale を追随させなかったのではないかということです。 「Emacs の language environment は基本的に、何かが違ったら言語じゃなくて も違う『言語』になる」という、守岡さんの言に従うなら、ja_JP.UTF-8 や ja_JP.eucJP などに対しても、define-language-environment により新たな言語 環境を定義すべきですよね。それも、pgg.el の中でやるべきなのでしょうか。 僕は、界面というものは、あるライブラリについて必ずしも唯一とは限らないと 考えています。例えば、同期/非同期などの特定の semantics、特定の実装法、 粒度、等の様々な面で切ったものこそが界面 (まさにその名前のまま) ではあり、 その場合、界面の一貫性とは単に切断面の選びかたに過ぎないのではないかと。 その意味で、(きっと冗談でしょうが) 守岡さんの仰る binary-funcall などを 用意するというのも一つの方法なのではないかと考えます。例えば Java では、 特定のコンテナに対し同期的なアクセスを保証する(型に変換する)ために、 Collections.synchronizedList (new ArrayList (...)) などという界面を用意 しています。 ;; 一応は常に前向きな姿勢ではあります。ただ、中途半端にやるくらいなら、何も ;; しないほうが (つまり Emacs の その時点の auto conversion に任せたほうが) ;; 喜ばれるのは確かなのではないでしょうか。 ともあれ、本気で説得する気があるのでしたら、pgg.el に入れるべき設定を 一部でも良いので、実際に見せてください。 -- Daiki Ueno From ueno ＠ bug.org Fri Dec 22 23:59:46 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 22 Dec 2000 23:59:46 +0900 Subject: binary-start-process In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "22 Dec 2000 17:12:11 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> Message-ID: <87itocy00t.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00764] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> 良くは把握してないのですが、原理的に考えれば、言語というのは nest 守岡> すると思うので、大本の emacs 全体の locale が必要なのは当然だと思 守岡> います。これにかぶさる形で、buffer の言語があり、buffer 内の文書の 守岡> 中でまた別の言語の文や単語を引用してたり含んでたりするというような 守岡> 階層構造になると思います。 「言語というのは nest する」という部分でくらくら来てしまったのですが、 ;; この程度の階層構造の存在を論じるのなら nest しないものなど、 ;; この世にあるのでしょうか？ akr さんの翻訳により、少しだけ理解できた気がするので、一通りまとめておきます。 現在の Emacs の language environment は POSIX locale model と比較して 大雑把すぎるため、将来的には java.util.Locale のような、言語コード、 国別コード、バリアントコード程度は表現できるような実装が現れることを、 期待している。新しい界面は以下のようであるべき： Variable: default-language-environment 環境変数から決定する locale に対応する言語環境。 Function: set-default-language-environment (OBJECT) default-language-environment を locale object (OBJECT) に設定する。 Variable: current-language-environment buffer 毎に決定される言語環境。 Function: set-language-environment (OBJECT) current-language-environment を locale object (OBJECT) に設定する。 Function: make-language-environment (LANGUAGE &optional COUNTRY VARIANT) locale object を生成する。 Function: language-environment-language-code (OBJECT) locale object の言語コードを取得する。 Function: language-environment-country-code (OBJECT) locale object の国別コードを取得する。 Function: language-environment-variant-code (OBJECT) locale object のバリアントコードを取得する。 Function: language-environment-list () 利用可能な locale object の一覧を取得する。 現状の "Japanese", "English", ... のような言語環境名は、将来導入される locale object への alias として実装される。 外部コマンドを起動する際には、その文脈における言語環境が、 process-environment に影響を与える。coding-priority-list に関しても適宜 変更を受ける。 mime-play-entity や pgg-scheme-verify のような、外部プログラムを呼ぶ可能 性のあるあらゆるモジュールは、将来、このような界面が実現した暁に容易に移 行できるような形にしておきたい。 [...] と、ここまでは理解可能なのですが、 このような架空の言語環境に関する API を前提としているにも関わらず、 現状の language-info-alist を利用して解決を図るのはいかがなものかと思います。 もしこのような界面を私が設計するとしたら、language-info-alist は撤廃する でしょう。これは、現在でいうところの file-coding-system-alist や gnus-posting-styles のようなものにすぎないと思います。また個人的にも、 pgg.el に 29 以上の言語環境における設定を入れたくはありません。 もし、以上が、完全な誤解であるとしたら申し訳ありません。 -- Daiki Ueno From Makoto.Nakagawa ＠ jp.compaq.com Mon Dec 25 10:16:16 2000 From: Makoto.Nakagawa ＠ jp.compaq.com (=?ISO-2022-JP?B?GyRCQ2ZAbhsoQiA=?= =?ISO-2022-JP?B?GyRCQD8bKEI=?=) Date: Mon, 25 Dec 2000 10:16:16 +0900 Subject: [cmail 9517] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "21 Dec 2000 16:30:18 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> Message-ID: <1191-Mon25Dec2000101616+0900-Makoto.Nakagawa@jp.compaq.com> 中川＠コンパック(株)です。 In message "[cmail 9517] Re: FLIM 1.14 and SEMI 1.14" on 00/12/21, 守岡 知彦 / MORIOKA Tomohiko wrote: > poe 依存性除去の関係から、define-obsolete-function-alias が使えなくなっ > たので、そのせいでめんどくさくなってつい eword-decode-header への > obsolete alias を comment out してしまったんですが、まだ必要でしょうか？ > もし、必要なら flim-1_14 枝に新たに作った FLIM-API.en に > [Function] eword-decode-header (&optional code-conversion separator) > As same as `mime-decode-header-in-buffer', q.v. > [Optional] (Usage: cmail 2.61) eword-decode-header がなくなっても cmail 側も困らないと思います。 それよりも、対応するバージョンの semi で (autoload 'eword-decode-header "eword-decode" "Decode MIME encoded-words in header fields." t) となっている部分を先に mime-decode-header-in-buffer に変更した方がよいの ではないでしょうか。 -------------- next part -------------- -- /*** Compaq Computer K.K. ***/ /*** Manufacturing Industry Practice/Professional Service ***/ /*** Nakagawa, Makoto（中川　誠） ***/ /*** 0B33 EAC3 F2F6 3D10 D9E9 AE7F 8EDA 44F9 1D29 D44A ***/ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/pgp-signature サイズ: 232 バイト 説明: 無し URL: From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 14:13:52 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 14:13:52 +0900 Subject: [cmail 9517] Re: FLIM 1.14 and SEMI 1.14 In-Reply-To: Makoto.Nakagawa@jp.compaq.com's message of "Mon, 25 Dec 2000 10:16:16 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <1191-Mon25Dec2000101616+0900-Makoto.Nakagawa@jp.compaq.com> Message-ID: >>>>> In [emacs-mime-ja : No.00770] >>>>> "中川さん" = Makoto.Nakagawa ＠ jp.compaq.com (中川 誠) wrote: 中川さん> eword-decode-header がなくなっても cmail 側も困らないと思い 中川さん> ます。 中川さん> それよりも、対応するバージョンの semi で 中川さん> (autoload 'eword-decode-header "eword-decode" 中川さん> "Decode MIME encoded-words in header fields." t) 中川さん> となっている部分を先に mime-decode-header-in-buffer に変更し 中川さん> た方がよいのではないでしょうか。 はい。そうですね。 また、この `mail-setup-hook' で header を decode する code は現在では 多分不要かおかしいので、とりあえず削ってみました。 -- 守岡 知彦 (MORIOKA Tomohiko) From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 14:47:02 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 14:47:02 +0900 Subject: [binary-*] (Re: binary-start-process) In-Reply-To: Daiki Ueno's message of "22 Dec 2000 21:31:55 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87lmt8y6v8.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00768] >>>>> "Daiki" = Daiki Ueno wrote: ;; binary-* と『言語』を分けて議論させてください。とりあえず、この記事 ;; では binary-* 関連に限定して述べます。 守岡> また、敢えて、binary-* のような専用の関数を設けることの利点を述 守岡> べるなら、将来、入出力での変換の制御のためのより良い汎用の機構が 守岡> できた時にも容易に実装できそうだという可能性が高そうだということ 守岡> もあると思います。let で囲む方法ではこの点が困難だと思います。ま 守岡> あ、そんな将来のことなんて知ったことではないとは思いますが。 Daiki> ううむ。個人的にはまったく逆の立場で、dynamic binding のほうが Daiki> まだ、移行は簡単ではないかという感想を抱いているのですが、専用 Daiki> の関数を設けることで移行の手間が減少する例を挙げて頂けないでしょ Daiki> うか。 dynamic binding というのは let で coding-system-for-{read|write} を束 縛する方法でしょうか？それとも as-binary-* みたいなのも含めてでしょう か？ pces では、let で特定の変数を囲む代わりに、専用の関数・macro を設けて 可搬性を実現していますが、これは１つの解だと思っています。 また、個人的には、命名規則が組織的に構成されていれば関数名が多くても構 わないのではないかという気もしないではないのですが（例えば、可能なら関 数を組織的に合成するような実装をすれば、そんなに大変じゃないかも）、と はいうものの、維持するのにコストがかかるのも確かだと思います。また、 APEL との兼ね合いで考えれば、pces と同種のものを FLIM で維持するのはば かばかしいとも考えられます。 直接的に FLIM で必要なのは、Content-Transfer-Encoding としての "7bit", "8bit", "binary" であり、text 入出力における coding-system での変換を 抑制するための機能ではないと考えられます。そこで、mime- 汎用や "base64" 用などと同様の "7bit", "8bit", "binary", "binary" 用符号・復 号ファイル入出力関数を用意してみました。また、smtpmail.el 実装上の便宜 のために、同種の例外的関数として binary-find-file-noselect を設けてみ ましたが、これは API としない方が良いかもしれません。 また、process に対する binary 入出力のために専用の関数群を設けず、 binary-funcall と binary-to-text-funcall を設けてみました。これは用法 的には as-binary-* に似たものになりますが、macro ではなく関数とします。 現状では、dynamic binding で実装していますが、仮に dynamic binding で ない環境で使うとしても、引数で取る関数を対応する関数で置き換えるような 実装が可能になるのではないかと思っています。 これに伴い、raw-io.el は廃止してみました。 Daiki> 僕は、界面というものは、あるライブラリについて必ずしも唯一とは Daiki> 限らないと考えています。例えば、同期/非同期などの特定の Daiki> semantics、特定の実装法、粒度、等の様々な面で切ったものこそが界 Daiki> 面 (まさにその名前のまま) ではあり、その場合、界面の一貫性とは Daiki> 単に切断面の選びかたに過ぎないのではないかと。 これは全く同感です。 Daiki> その意味で、(きっと冗談でしょうが) 守岡さんの仰る Daiki> binary-funcall などを用意するというのも一つの方法なのではないか Daiki> と考えます。例えば Java では、特定のコンテナに対し同期的なアク Daiki> セスを保証する(型に変換する)ために、 Daiki> Collections.synchronizedList (new ArrayList (...)) などという界 Daiki> 面を用意しています。 実は本気だったのです。 というわけで、とりあえず、この方面でやってみました。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From okazaki ＠ be.to Mon Dec 25 14:48:46 2000 From: okazaki ＠ be.to (OKAZAKI Tetsurou) Date: Mon, 25 Dec 2000 14:48:46 +0900 Subject: broken mime-example In-Reply-To: <87elzy90g9.fsf@gg.bug.org> References: <87elzy90g9.fsf@gg.bug.org> Message-ID: <8666k9nj9d.wl@dolphin.be.to> In the ML [emacs-mime-ja 00683] Daiki Ueno wrote: > >>>>> In [emacs-mime-ja : No.00681] > >>>>> okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote: > > > .mime-exampleが、なんらかの理由で壊れている場合、 > > > emacs-20.7 などで、SEMI をバイトコンパイルすると、 > > > > > > While compiling toplevel forms in file /home/kokada/cvs/m17n/semi/mime-pgp.el: > > > !! error (("Invalid character: 0331200, 111232, 0x1b280")) > > > > > > のようなエラーが出るようです． 私もつい最近、同じ様なエラーを体験しました。~/.mime-example の中身が 壊れている事が原因だと気づくまでに、しばらくかかってしまいました。 While compiling toplevel forms in file /usr/home/refactor/works/usr/home/refactor/Ports/edit ors/semi-emacs20-current/work/semi-1_14-200012150500/mime-pgp.el: !! Invalid read syntax ((".")) 調べてみたら、~/.mime-example がこんなんなってました。:-) -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: .mime-example.error 型: application/octet-stream サイズ: 370 バイト 説明: 無し URL: -------------- next part -------------- > > そもそも、該当の部分をmake時に読み込む必要はないですよね． > 具体的には、現在 mime-view の toplevel に書かれている、 > mime-{preview|acting}-siguation-example-list の設定箇所を > (eval-after-load "mime-view" ...) で括って、semi-setup.el に入れてしまえ > ばどうかと思うのですが、如何でしょうか？ 私は賛成します。もちろん、byte-compile時ではなく、実行時にのみ 読み込む様にしても、error message に関しては [emacs-mime-ja 00681] と同様の変更をした方が良いと思います。 -- 岡崎哲朗 From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 15:21:40 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 15:21:40 +0900 Subject: language in SEMI and Mule (Re: binary-start-process) In-Reply-To: Daiki Ueno's message of "22 Dec 2000 21:31:55 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87lmt8y6v8.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00768] >>>>> "Daiki" = Daiki Ueno wrote: 守岡> language-info-alist は何でもありですから、適当な機構を PGG が提 守岡> 供することにより、それを使った設定を set-language-environment と 守岡> 同期して行うことは可能です。 Daiki> これは必要なのでしょうか？ 守岡> 判りませんが、やろうと思ったらかなり何でもできるということを言っ 守岡> ているだけです。 Daiki> 何でもできるのでしたら、PGG の場合の、守岡さんの提唱する界面に Daiki> おける、言語環境の設定を見せて頂けませんか？ ;; 不完全なもので Daiki> も構いません。 現状を前提にとりあえずの解決を行う場合、PGG 専用の set-language-environment で設定可能な変数や関数などを設けるのが良いの ではないかと思っています。そうすれば、set-language-environment で PGG の設定を行うことができます。この場合、その default value が `undecided' であるのは構わないと思います。しかし、coding category や priority の設定と別に PGG に関する（heuristic な）設定ができる余地があっ た方が良いと思います。 この時、もし、（PGG の外部から見て(*1)）PGG が locale と coding-system の関係を管理してくれるなら、使用する locale（ないしは、『言語環境』、 あるいはそれに相当するもの）を指定するための API があれば良いと思いま す。 (*1) 実際には、PGG 自身ではなく、そうしたことを行う汎用の module に分 離されており、それを用いる場合を含みます。 もし、PGG が locale と coding-system の関係を管理しないなら、 coding-system と locale（ないしは、『言語環境』、あるいはそれに相当す るもの）が指定できるのが望ましいと思います。 Daiki> ここで Emacs 21 の例を出したのは、Emacs 21 の実装を基準とすると Daiki> いうよりも、むしろ、XEmacs の auto-language-alist を見ればわか Daiki> るように、locale nameと言語環境の対応付けが 1:1 ではないために、 Daiki> Emacs 21 はあえて言語環境の変化に system-messages-locale を追随 Daiki> させなかったのではないかということです。 これは判ります。 個人的に現在構想しているのは、言語、地域、文字符号、OS, その他検出可能 なさまざまな情報を key に、これらの間の制約を calist みたいなので記述 する枠組を設ける方法です。そして、この記述の枠組に基づいて良くある組合 せを記述した database を作ります。この database を用いて、現在の実行環 境で言語や locale の情報を補完する問い合わせ関数を設けます。ここで、一 意に決められない場合は、利用者への問い合わせ関数を呼び出せるようにし、 利用者が選択できるようにします。この選択結果は利用者の用例 database に 保存され、次回以降の補完に用います。（つまり、SEMI MIME-View での方法 と同様の方法です） Daiki> 「Emacs の language environment は基本的に、何かが違ったら言語 Daiki> じゃなくても違う『言語』になる」という、守岡さんの言に従うなら、 Daiki> ja_JP.UTF-8 やja_JP.eucJP などに対しても、 Daiki> define-language-environment により新たな言語環境を定義すべきで Daiki> すよね。それも、pgg.el の中でやるべきなのでしょうか。 それはそうは思いません。ただ、message でよく用いられる CES の傾向性と、 『言語環境』の coding-system の優先度（それに、利用者の locale の設定 など）から、それらしい PGG の表示 message 用の coding-system と『言語_ 地域』を設定可能なのではないかと思いました。もちろん、これは heuristic であり、うまくいくとは限りませんが、でも、coding-system と『言語_地域』 から『言語_地域.符号』を作る場合、存在しなければ C locale を作ってくれ る場合が多いと思うので、少なくとも文字化けは避けられるのではないかと思 います。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From ueno ＠ bug.org Mon Dec 25 15:52:12 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 25 Dec 2000 15:52:12 +0900 Subject: language in SEMI and Mule (Re: binary-start-process) In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "25 Dec 2000 15:21:40 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87lmt8y6v8.fsf@gg.bug.org> Message-ID: <87snnd56xv.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00774] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> language-info-alist は何でもありですから、適当な機構を PGG が提 守岡> 供することにより、それを使った設定を set-language-environment と 守岡> 同期して行うことは可能です。 守岡> 判りませんが、やろうと思ったらかなり何でもできるということを言っ 守岡> ているだけです。 Daiki> 何でもできるのでしたら、PGG の場合の、守岡さんの提唱する界面に Daiki> おける、言語環境の設定を見せて頂けませんか？ ;; 不完全なもので Daiki> も構いません。 守岡> 現状を前提にとりあえずの解決を行う場合、PGG 専用の 守岡> set-language-environment で設定可能な変数や関数などを設けるのが良 守岡> いのではないかと思っています。そうすれば、set-language-environment 守岡> で PGGの設定を行うことができます。 いや、ですから、何度も言うように、それが僕には判りません。 守岡さんの想定する language environment のモデルとは多重度の異なる現状の language-info-alist で、本当に何でもできるのでしたら、コードを見せてくだ さい。 この場合、"v" (mime-play-entity) から呼ばれる外部コマンドのうち、gettext により表示の振舞いが直交化されているものは、全て *MIME echo* に、message が化けずに表示されると思うのですが、これは実現できているのでしょうか？ ;; 僕が岡田さんを誠意がないと責めたときには、sasl.el の API と ;; サンプルの実装、UML による図式などを提供しましたが、 ;; 今回の守岡さんの場合、何もせずに単にだだをこねているようにしか思えません。 -- Daiki Ueno From kajino ＠ nis.nec.co.jp Mon Dec 25 16:14:37 2000 From: kajino ＠ nis.nec.co.jp (kajino ＠ nis.nec.co.jp) Date: Mon, 25 Dec 2000 16:14:37 +0900 Subject: "MIME encodeing" includes too much space. Message-ID: <200012250714.eBP7Ecx12390@2SI.NSI.ksp.nis.nec.co.jp> はじめまして梶野と申します。 APEL 10.2 FLIM 1.14.0 (新ノ口) SEMI 1.14.0 (動橋) EMH 1.14.0 の環境に移行してから、MIME encoding に余分なスペースが入る ようになりました。 たとえば、Subject: に 「１２３４５６７８９０１２３４５６７８９０」 と記述すると Subject: １２３４５６７８９０１２３４５ ６７８９０ と encoding され、2つめのブロックに 「 ６７８９０」という余計なスペースが混入しています。 ^ おそらくは、APEL の version に依存しているのではないかと 思います。(APEL-9.23 では問題なかったと記憶していますので。) APEL 200012220426 FLIM 1.14.1 SEMI 1.14.1 EMH 1.14.0 においても状況は同じした。 #単なるユーザなので、状況報告だで、申し訳ありません。 以上です。 /////////////////////////////////// NEC informatec systems Co.,ltd. Network SI Div., 2nd SI Dept. kajino ＠ ksp.nis.nec.co.jp From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 16:48:50 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 16:48:50 +0900 Subject: language in SEMI and Mule (Re: binary-start-process) In-Reply-To: Daiki Ueno's message of "25 Dec 2000 15:52:12 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87lmt8y6v8.fsf@gg.bug.org> <87snnd56xv.fsf@gg.bug.org> Message-ID: >>>>> In <87snnd56xv.fsf ＠ gg.bug.org> >>>>> "Daiki" = Daiki Ueno wrote: 守岡> 現状を前提にとりあえずの解決を行う場合、PGG 専用の 守岡> set-language-environment で設定可能な変数や関数などを設けるのが 守岡> 良いのではないかと思っています。そうすれば、 守岡> set-language-environment で PGGの設定を行うことができます。 Daiki> いや、ですから、何度も言うように、それが僕には判りません。 一番簡単なのは pgg-*-coding-system みたいな変数を設けることだと思いま す。そうすれば、PGG を用いる側が確実に設定を行うことが出来ます。 Daiki> 守岡さんの想定する language environment のモデルとは多重度の異 Daiki> なる現状のlanguage-info-alist で、本当に何でもできるのでしたら、 Daiki> コードを見せてください。 すみません。この文章が解析できません。 「現状の language-info-alist で、本当に何でもできる」ということに関し ていえば、言語や利用者が属する環境に適した振舞をするということの理想形 が実現できるかという意味では、出来ないと思います。 ただ、ある枠組の中で設定したいことが十分に設定できるかという意味であれ ば、*-function 属性を hook したり、`set-language-environment-hook' を 用いることにより、かなりの設定が可能だと思います。 Daiki> この場合、"v" (mime-play-entity) から呼ばれる外部コマンドのうち、 Daiki> gettextにより表示の振舞いが直交化されているものは、全て *MIME Daiki> echo* に、messageが化けずに表示されると思うのですが、これは実現 Daiki> できているのでしょうか？ もちろん、現状では残念ながら実現していません。 -- tomo. P.S. Daiki> ;; 僕が岡田さんを誠意がないと責めたときには、sasl.el の API と Daiki> ;; サンプルの実装、UML による図式などを提供しましたが、今回の守 Daiki> ;; 岡さんの場合、何もせずに単にだだをこねているようにしか思えま Daiki> ;; せん。 この件に関してはそう思われても仕方がありません。私は悲しいかな、上野さ ん程野元気や調査力、実装力、時間がありません。 ただ、私は上野さんと競争をしたり、上野さんを叩いたり、馬鹿にするために 実装したりモデル化したりしている訳ではありません。仮にそういうことをし たいと思っても、そんなことに割く資源はあまりないです。 正直言えば、私から見て、上野さんは技術的な観点でもって人格攻撃している ように見え、それを醜く感じ、嫌悪感を感じました。もし、それが私の誤解で あれば申し訳ありません。また、そのようなことをすることは上野さん自身を 損ない、上野さんが活躍する上での障害になるのではないかと危ぶみました。 これもまったくもって余計なお世話なんですが。そして、このような感情・感 覚から心無い言動をしてしまいました。 ただ、更に余計なことを述べれば、上野さんは自分の言動の行間を読むことを 他人に求め、また、上野さんの文脈・価値観で他人の言動の行間を読んでらっ しゃるように思われますが、これは大変危うい態度だと思います。みんなが上 野さんでない以上、どうしてそんなことが可能なんでしょうか？また、上野さ んが感じた行間は往々にして誤解になりかねないと思います。書いてないこと に勝手に腹をたてるようなことは止めた方がうまくコミュニケーション出来る のではないかと思います。 ;; まあ、もっとも、私自身が実行できているとは言いがたいことではあるの ;; ですが。 ;; 私の場合、往々にして私自身が私を知らないし、大抵相反する複数のこと ;; を思ってたりするので、それを収束させるのは困難です。 また、IRC は即時性があり、mail を補足する上で良い media だと思いますが、 複雑な内容を正確に伝えるのには向かないように思えます。また、 emacs-mime-ja の読者は必ずしも IRC に参加しておらず、mailing list がそ の性質上、送り先だけに宛てられたものでない以上、IRC とは切り離し、 mailing list で完結した議論を行って頂けると幸いです。IRC で生じた議論 の続きを mailing list で行うのは良いと思いますが、その場合、背景説明が 必要だろうと思います。 いずれにせよ、失礼なことをお書きし、上野さんを御不快にさせてしまったこ とを謝ります。私としては、上野さんを尊敬する友人の一人としておつき合い させて頂きたいと思っております。もちろん、お許し頂けるならばですが。 From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 19:01:07 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 19:01:07 +0900 Subject: FLIM 1.14.2 =?ISO-2022-JP?B?KBskQkgsTFpAPjh9GyhCKQ==?= Message-ID: [Status] alpha [Recommended environment] APEL: 10.2 [Changes] 2000-12-25 MORIOKA Tomohiko * FLIM: Version 1.14.2 (Yagi-Nishiguchi) released. 2000-12-23 MORIOKA Tomohiko * smtpmail.el (smtpmail-send-it): Use `binary-write-decoded-region' instead of `binary-write-region'. * mmexternal.el (mmexternal-require-buffer): Use `binary-insert-encoded-file' instead of `binary-insert-file-contents'. (mime-write-entity-body): Use `binary-write-decoded-region' instead of `binary-write-region'. * mmbuffer.el (mime-write-entity-body): Use `binary-write-decoded-region' instead of `binary-write-region'. * mel.el: - Don't require `raw-io'. (8bit-insert-encoded-file): New function. (8bit-write-decoded-region): New function. (7bit-insert-encoded-file): New alias. (7bit-write-decoded-region): New alias. (binary-insert-encoded-file): New alias. (binary-find-file-noselect): New function. (binary-funcall): New function. (binary-to-text-funcall): New function. (mime-insert-encoded-file of "base64"): Use `binary-insert-encoded-file' instead of `binary-insert-file-contents'. * FLIM-API.en (base64-decode-string): New function. (base64-encode-string): New function. (ENCODING-write-decoded-region): New function. (ENCODING-insert-encoded-file): New function. * raw-io.el: Deleted. * FLIM-ELS (flim-modules): Delete `raw-io'. 2000-12-22 MORIOKA Tomohiko * smtp.el (smtp-open-connection-function): Revert initial value to `open-network-stream'. (qmtp-open-connection): Use `binary-funcall'. * qmtp.el (qmtp-open-connection-function): Revert initial value to `open-network-stream'. (qmtp-send-buffer): Use `binary-funcall'. 2000-12-23 OKAZAKI Tetsurou * FLIM-ELS (flim-modules): Delete `mmdbuffer'. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/flim/flim-1.14/ -------------- next part -------------- -- tomo. From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 19:04:59 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 19:04:59 +0900 Subject: SEMI 1.14.2 =?ISO-2022-JP?B?KBskQkJnQDs7exsoQik=?= Message-ID: [Status] alpha [Required Environment] APEL: 9.22 (or later) FLIM: 1.14.2 [Changes] 2000-12-25 MORIOKA Tomohiko * SEMI: Version 1.14.2 (Daishōji) released. * README.en (Required environment): Update to FLIM 1.14.2. * mail-mime-setup.el (mail-setup-hook): Don't add `eword-decode-header'. 2000-12-23 MORIOKA Tomohiko * mime-view.el (mime-view-define-keymap): Return `mime-view-mode-map' instead of set up as local keymap; don't call `mime-view-define-keymap-hook'. (mime-display-message): Add new optional argument `keymap'. * mime-play.el (mime-store-message/partial-piece): Use `binary-insert-encoded-file' and `binary-write-decoded-region' instead of `binary-insert-file-contents' and `binary-write-region'. 2000-12-23 MORIOKA Tomohiko * smime.el (smime-process-region): Use `binary-funcall' instead of `binary-start-process-shell-command'. (smime-verify-region): Use `binary-write-decoded-region' and `binary-insert-encoded-file' instead of `binary-write-region' and `binary-insert-file-contents'. * pgg-pgp5.el (pgg-pgp5-messages-coding-system): New variable. (pgg-pgp5-process-region): Use `binary-to-text-funcall' instead of `binary-start-process-shell-command'. (pgg-scheme-verify-region): Use `binary-write-decoded-region' instead of `binary-write-region'. * pgg-pgp.el (pgg-pgp-messages-coding-system): New variable. (pgg-pgp-process-region): Use `binary-to-text-funcall' instead of `binary-start-process-shell-command'. (pgg-scheme-verify-region): Use `binary-write-decoded-region' instead of `binary-write-region'. * pgg-gpg.el (pgg-gpg-process-region): Use `binary-to-text-funcall' instead of `binary-start-process'. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/semi/semi-1.14-for-flim-1.14/ -------------- next part -------------- -- tomo. From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Dec 25 19:11:08 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 25 Dec 2000 19:11:08 +0900 Subject: EMH 1.14.1 Message-ID: [Status] alpha [Required Environment] APEL: 9.22 or later FLIM: 1.14.2 or later SEMI: 1.14.2 or later [Changes] 2000-12-25 MORIOKA Tomohiko * EMH: Version 1.14.1 released. * emh.el (mh-display-msg): Use `8bit-insert-encoded-file' instead of `raw-text-insert-file-contents'. -------------- next part -------------- It is available from ftp://ftp.jaist.ac.jp/pub/GNU/elisp/emh/ -------------- next part -------------- -- tomo. From ueno ＠ bug.org Tue Dec 26 00:50:20 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 26 Dec 2000 00:50:20 +0900 Subject: language in SEMI and Mule (Re: binary-start-process) In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "25 Dec 2000 16:48:50 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87lmt8y6v8.fsf@gg.bug.org> <87snnd56xv.fsf@gg.bug.org> Message-ID: <87zohkec03.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00778] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> 現状を前提にとりあえずの解決を行う場合、PGG 専用の 守岡> set-language-environment で設定可能な変数や関数などを設けるのが 守岡> 良いのではないかと思っています。そうすれば、 守岡> set-language-environment で PGGの設定を行うことができます。 Daiki> いや、ですから、何度も言うように、それが僕には判りません。 守岡> 一番簡単なのは pgg-*-coding-system みたいな変数を設けることだと思いま 守岡> す。そうすれば、PGG を用いる側が確実に設定を行うことが出来ます。 いや、ですから、それは僕が最初に守岡さんに提示した解答に過ぎません。 ;; IRC のログを公開しても良いですか？ 「set-language-environment で PGG の設定を行うことができ」るのなら、 その設定を具体的に見せてください。 ;; できないのなら、近似解にはなり得ないと思うのですが。 守岡> ただ、ある枠組の中で設定したいことが十分に設定できるかという意味であれ 守岡> ば、*-function 属性を hook したり、`set-language-environment-hook' を 守岡> 用いることにより、かなりの設定が可能だと思います。 というわけで、この設定を見せてください。 Daiki> この場合、"v" (mime-play-entity) から呼ばれる外部コマンドのうち、 Daiki> gettextにより表示の振舞いが直交化されているものは、全て *MIME Daiki> echo* に、messageが化けずに表示されると思うのですが、これは実現 Daiki> できているのでしょうか？ 守岡> もちろん、現状では残念ながら実現していません。 ということは、SEMI の中にさえある、AOP における crosscutting のような 切断面は界面として認識されているということですね。 ;; ラングとパロールのような意味不明の比喩では、先に唯一界面(指向対象)ありき、 ;; のような感を受けますので。 P.S. 守岡> この件に関してはそう思われても仕方がありません。私は悲しいかな、上野さ 守岡> ん程野元気や調査力、実装力、時間がありません。 当然、僕も時間はありませんし、悲しいかな、国際化に関する興味もありません。 ;; 面白い問題を面白い枠組として提示して頂けるなら別ですが。 守岡> ただ、私は上野さんと競争をしたり、上野さんを叩いたり、馬鹿にするために 守岡> 実装したりモデル化したりしている訳ではありません。仮にそういうことをし 守岡> たいと思っても、そんなことに割く資源はあまりないです。 僕も、当然ながら、岡田さんと競争をしたり、岡田さんを叩いたり、馬鹿にする ために実装したりモデル化したりしている訳ではありません。 守岡> 正直言えば、私から見て、上野さんは技術的な観点でもって人格攻撃している 守岡> ように見え、それを醜く感じ、嫌悪感を感じました。もし、それが私の誤解で 守岡> あれば申し訳ありません。また、そのようなことをすることは上野さん自身を 守岡> 損ない、上野さんが活躍する上での障害になるのではないかと危ぶみました。 守岡> これもまったくもって余計なお世話なんですが。そして、このような感情・感 守岡> 覚から心無い言動をしてしまいました。 協同開発において、モデルやコード、ユースケースすらも提示できない実体は、 存在しないも同然ではないかと考えています。 岡田さん御自身が Wanderlust という特定の MUA に入れた、SLIM のための glue code を、「現在動作しているから変更したくない」というのは、 あまりにも無責任すぎませんか？ ;; これは、bug report を無視するのと同じレベルだと考えています。 コードを書くというのは、文章を書くのと同様に、それなりに責任を負わねば ならないものだと思います。その上で、将来的に再利用可能なコードを書くのは、 責任の所在をできるかぎり最小化する試みではないかと。 ;; 原作者が一生メンテナンスするというのであれば、話は別ですが。 守岡> ただ、更に余計なことを述べれば、上野さんは自分の言動の行間を読むことを 守岡> 他人に求め、また、上野さんの文脈・価値観で他人の言動の行間を読んでらっ 守岡> しゃるように思われますが、これは大変危うい態度だと思います。みんなが上 守岡> 野さんでない以上、どうしてそんなことが可能なんでしょうか？また、上野さ 守岡> んが感じた行間は往々にして誤解になりかねないと思います。書いてないこと 守岡> に勝手に腹をたてるようなことは止めた方がうまくコミュニケーション出来る 守岡> のではないかと思います。 本当に正確に伝えたいと思うのでしたら、そう勘繰られないような形式的な文章、 もしくはコードを書くべきではないでしょうか。 -- Daiki Ueno From ueno ＠ bug.org Tue Dec 26 13:38:47 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 26 Dec 2000 13:38:47 +0900 Subject: binary-start-process In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "25 Dec 2000 16:00:22 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> Message-ID: <87ae9jg5k8.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00776] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> 個人的に構想しているのは、別の記事に書いたような、calist (next 守岡> generation) みたいなので実現される『言語状況オブジェクト』みたいなので 守岡> す。ただ、当然、ここでは言語コード、国別コード、バリアントコード程度は 守岡> 表現可能であるような枠組になります。 最初に断っておくと、ここに挙げたのは、僕自身の language environment 構想 ではなく、守岡さんの想定していると思われる界面を、現行の language environment と 100% の互換性を持つという前提のもとに、整理してみたにすぎません。 当然ながら、この界面を実装する義務も予定もありません。 また、僕は PGG という SEMI で用いられる下位の暗号化ライブラリの設計者で あって、国際化の専門家ではありませんし、そうなりたいとも思いません。 Daiki> Function: set-default-language-environment (OBJECT) Daiki> default-language-environment を locale object (OBJECT) に設定する。 守岡> と Daiki> Function: set-language-environment (OBJECT) Daiki> current-language-environment を locale object (OBJECT) に設定する。 守岡> はそれぞれ locale object (OBJECT) を default-language-environment / 守岡> current-language-environment に設定した方が良いのではないでしょうか？ 日本語の問題ですね。そう読めませんか？ 守岡> それとも、（現行の）Emacs の language environment とは別立てで、locale 守岡> object (OBJECT) を考えてらっしゃるのでしょうか？ Daiki> 現状の "Japanese", "English", ... のような言語環境名は、将来導 Daiki> 入されるlocale object への alias として実装される。 守岡> というか、名前とオブジェクトの双方が取れるようにするのが良いかなと思い 守岡> ます。 もちろんそうなります。 守岡> 現状の language-info-alist に基づく枠組でも、将来の枠組でも、出来るだ 守岡> け適切に言語が設定され、少なくとも文字化けが起こらないことを可能な限り 守岡> 保証することが実現可能な API が PGG に欲しいと思います。 現状の language-info-alist に基づく枠組でも、将来の枠組でも、出来るだ け適切に言語が設定され、少なくとも文字化けが起こらないことを可能な限り 保証することが実現可能な API が mime-play-entity にも欲しいと思います。 守岡> ;; むしろ、私が密かに願っていたのは、pgg で使用するより良い言語環境に 守岡> ;; 関する枠組を汎用的な形で上野さんが作ってくれることだったんですが、 守岡> ;; これはないものねだりと言わざるを得ないでしょう。 最初からそう言うべきでしょう。 巧妙に犯人を PGG に押しつけることで、僕に仕事を回そうとしたその態度に、 とても腹を立てています。 -- Daiki Ueno From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue Dec 26 16:29:34 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 26 Dec 2000 16:29:34 +0900 Subject: language in SEMI and Mule (Re: binary-start-process) In-Reply-To: Daiki Ueno's message of "26 Dec 2000 00:50:20 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87lmt8y6v8.fsf@gg.bug.org> <87snnd56xv.fsf@gg.bug.org> <87zohkec03.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00782] >>>>> "Daiki" = Daiki Ueno wrote: 守岡> 現状を前提にとりあえずの解決を行う場合、PGG 専用の 守岡> set-language-environment で設定可能な変数や関数などを設けるのが 守岡> 良いのではないかと思っています。そうすれば、 守岡> set-language-environment で PGGの設定を行うことができます。 Daiki> いや、ですから、何度も言うように、それが僕には判りません。 守岡> 一番簡単なのは pgg-*-coding-system みたいな変数を設けることだと 守岡> 思います。そうすれば、PGG を用いる側が確実に設定を行うことが出来 守岡> ます。 Daiki> いや、ですから、それは僕が最初に守岡さんに提示した解答に過ぎま Daiki> せん。 はい、その通りです。 Daiki> ;; IRC のログを公開しても良いですか？ ;; 必要があるならどうぞ。かなり馬鹿なことを言っていたと思うので、不適 ;; 切なことは訂正し、また、必要なら謝罪します。 Daiki> 「set-language-environment で PGG の設定を行うことができ」るのなら、 Daiki> その設定を具体的に見せてください。 判りました。 例えば、PGG に変数 pgg-messages-coding-system と pgg-messages-locale があるとして、それが language-info-alist の pgg-messages-coding-system 属性と pgg-messages-locale 属性で表現されているとすると、 (defun pgg-setup-locale () (setq pgg-message-locale (get-language-info current-language-environment 'pgg-message-locale) pgg-message-coding-system (get-language-info current-language-environment 'pgg-message-coding-system))) (add-hook 'set-language-environment-hook 'pgg-setup-locale) で設定できると思います。 -- tomo. P.S. 守岡> この件に関してはそう思われても仕方がありません。私は悲しいかな、 守岡> 上野さん程野元気や調査力、実装力、時間がありません。 Daiki> 当然、僕も時間はありませんし、悲しいかな、国際化に関する興味も Daiki> ありません。 はい。それはそれで良いと言って来たつもりです。でも、興味がないからといっ て undecided で良いだろうと言われるとちょっと悲しい訳です。 ;; 少し被害妄想的に言えば、私が関心を寄せる分野について冷淡ないしは尊 ;; 重されていない感を受けました。もっとも、これは毎度のことではあるの ;; ですが。そして、他罰的な感を受けました。 Daiki> ;; 面白い問題を面白い枠組として提示して頂けるなら別ですが。 残念ながら、上野さんがどのようなものを面白いと感じるかが判っていません でした。また、今も多分判っていません。 ただ、いずれにしても私の力が足らなかったのは申し訳ありません。 Daiki> 協同開発において、モデルやコード、ユースケースすらも提示できな Daiki> い実体は、存在しないも同然ではないかと考えています。 ここでいう実体とは何でしょうか？ Daiki> 岡田さん御自身が Wanderlust という特定の MUA に入れた、SLIM の Daiki> ためのglue code を、「現在動作しているから変更したくない」とい Daiki> うのは、あまりにも無責任すぎませんか？ 一般論としては同感です。 ただ、その時点の状況によって ad hoc な対処をせざるを得ないこともあると 思います。この場合も、その後の road map を明らかにした方が良いと思いま すが。 ただ、いずれにしてももう少しものの言いようがあるだろうという感想を持っ ています。また、モデルやコード、ユースケースをばーんと出せば良いという もんでもないでしょう。もう少し説明があった方が良いと思います。これらは つまる所、理解を共有するための言葉の一種だと思うので。もちろん、いずれ にせよコストはかかるのでするもしないも自由なんだと思いますが。 Daiki> ;; これは、bug report を無視するのと同じレベルだと考えています。 ;; これについては本当にすみません。実際にはとりあえず一箇所に溜ってい ;; れば少しずつでも対処していくつもりではあるんですが。近年はちょっと ;; 疲れ気味で特にこの面での意欲が減っていました。 Daiki> コードを書くというのは、文章を書くのと同様に、それなりに責任を Daiki> 負わねばならないものだと思います。 これはそう思います。 Daiki> その上で、将来的に再利用可能なコードを書くのは、責任の所在をで Daiki> きるかぎり最小化する試みではないかと。 これはちょっと良く判りません。 それも一つの方法なんだと思いますが。 Daiki> ;; 原作者が一生メンテナンスするというのであれば、話は別ですが。 重要なのは判りやすくすることだと思います。でも、判りやすさというのはそ う明らかなものではないので、いろんな手法が開発され続けているんだと思い ますが。 守岡> ただ、更に余計なことを述べれば、上野さんは自分の言動の行間を読む 守岡> ことを他人に求め、また、上野さんの文脈・価値観で他人の言動の行間 守岡> を読んでらっしゃるように思われますが、これは大変危うい態度だと思 守岡> います。みんなが上野さんでない以上、どうしてそんなことが可能なん 守岡> でしょうか？また、上野さんが感じた行間は往々にして誤解になりかね 守岡> ないと思います。書いてないことに勝手に腹をたてるようなことは止め 守岡> た方がうまくコミュニケーション出来るのではないかと思います。 Daiki> 本当に正確に伝えたいと思うのでしたら、そう勘繰られないような形 Daiki> 式的な文章、もしくはコードを書くべきではないでしょうか。 形式的ならばちゃんとコミュニケーションできるとは必ずしも思わないですが、 異質な文化間で最低限のコミュニケーションを行うためには真だと思います。 ;; ただ、code を書いてもとりあえずのものを理想的なものと勘違いされたり ;; する恐れがあると思うので、comment や説明文とかもいると思いますが、 ;; これを形式化するならば ISO や JIS の規格書のように語彙や概念、形式 ;; をまず定義する必要があると思います。もっとも、規格書の努力がむくわ ;; れているかというとあんまりそういう気もしないんですが（往々にして難 ;; しくなって理解しづらくなり、誤解されたり、伝えたいことが定義しきれ ;; なかったり、…）。で、そのために解説をつけたりする訳で、現実的にも ;; 形式主義には限界がある気がします。 From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue Dec 26 17:47:40 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 26 Dec 2000 17:47:40 +0900 Subject: binary-start-process In-Reply-To: Daiki Ueno's message of "26 Dec 2000 13:38:47 +0900" References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> Message-ID: >>>>> In [emacs-mime-ja : No.00783] >>>>> "Daiki" = Daiki Ueno wrote: Daiki> 最初に断っておくと、ここに挙げたのは、僕自身の language Daiki> environment 構想ではなく、守岡さんの想定していると思われる界面 Daiki> を、現行の language environment と 100% の互換性を持つという前 Daiki> 提のもとに、整理してみたにすぎません。 Daiki> 当然ながら、この界面を実装する義務も予定もありません。 Daiki> また、僕は PGG という SEMI で用いられる下位の暗号化ライブラリの Daiki> 設計者であって、国際化の専門家ではありませんし、そうなりたいと Daiki> も思いません。 はい。それは判っております。 Daiki> Function: set-default-language-environment (OBJECT) Daiki> default-language-environment を locale object (OBJECT) に設定する。 守岡> と Daiki> Function: set-language-environment (OBJECT) Daiki> current-language-environment を locale object (OBJECT) に設定する。 守岡> はそれぞれ locale object (OBJECT) を 守岡> default-language-environment / current-language-environment に設 守岡> 定した方が良いのではないでしょうか？ Daiki> 日本語の問題ですね。そう読めませんか？ つまり、実際には私が述べたようなものを述べようとなさっていた訳ですか？ そういう可能性もあるかなとも一瞬思いましたが、そうじゃない可能性に気づ いたのでお聞きしました。 そういう訳で、残念ながら日本語の問題とは判断できず、そうも読めませんで した。 守岡> それとも、（現行の）Emacs の language environment とは別立てで、 守岡> locale object (OBJECT) を考えてらっしゃるのでしょうか？ Daiki> 現状の "Japanese", "English", ... のような言語環境名は、将来導 Daiki> 入されるlocale object への alias として実装される。 守岡> というか、名前とオブジェクトの双方が取れるようにするのが良いかな 守岡> と思います。 Daiki> もちろんそうなります。 なるほど。 守岡> 現状の language-info-alist に基づく枠組でも、将来の枠組でも、出 守岡> 来るだけ適切に言語が設定され、少なくとも文字化けが起こらないこと 守岡> を可能な限り保証することが実現可能な API が PGG に欲しいと思いま 守岡> す。 Daiki> 現状の language-info-alist に基づく枠組でも、将来の枠組でも、出 Daiki> 来るだけ適切に言語が設定され、少なくとも文字化けが起こらないこ Daiki> とを可能な限り保証することが実現可能な API が mime-play-entity Daiki> にも欲しいと思います。 はい。私もそう思います。 守岡> ;; むしろ、私が密かに願っていたのは、pgg で使用するより良い言語 守岡> ;; 環境に関する枠組を汎用的な形で上野さんが作ってくれることだっ 守岡> ;; たんですが、これはないものねだりと言わざるを得ないでしょう。 Daiki> 最初からそう言うべきでしょう。 そうですね。でも、多分、私自身が良く判ってなかったのでしょう。無論、こ れは救いがたい私の問題です。 Daiki> 巧妙に犯人を PGG に押しつけることで、僕に仕事を回そうとしたその Daiki> 態度に、とても腹を立てています。 だから、何度も言っているように私は誰かや誰かを糾弾するつもりはありませ ん。これは作品に関しても同様です。それとも PGG は上野さんの縄張で、そ れを荒すと腹が立つんでしょうか？ ただ、確かに私は、誰かがやってくれるとうれしいので、上野さん以外にも、 やれそうな人だと思うとつい甘えたことを言ってしまうことが多いと思います。 で、これはたかりの一種で御不快に思われることは理解できます（でも、ここ まで激烈な反応を返されたのは驚きですが）。この件に関しても謝罪します。 ;; それから、もしかして、仕事というのが未踏を指しているのなら、未踏は ;; まだ契約できていませんし、事業がはじまるかどうかは現状では判りませ ;; ん。今は、それとは関係なく半田さんと共同で GNU Emacs 21 の RMAIL の ;; MIME 化を主要な目的としてやっています。締め切りは過ぎているというか、 ;; かなり厳しいので間に合うかどうか判りませんが…。 -- 守岡 知彦 (MORIOKA Tomohiko) From minakaji ＠ osaka.email.ne.jp Tue Dec 26 21:23:14 2000 From: minakaji ＠ osaka.email.ne.jp (NAKAJIMA Mikio) Date: Tue, 26 Dec 2000 21:23:14 +0900 Subject: =?ISO-2022-JP?B?GyRCJCIkTiQlIUEbKEI=?= f(^^;;; In-Reply-To: References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> Message-ID: At 26 Dec 2000 17:47:40 +0900, 守岡 知彦 / MORIOKA Tomohiko wrote: > Daiki> 巧妙に犯人を PGG に押しつけることで、僕に仕事を回そうとしたその > Daiki> 態度に、とても腹を立てています。 > > だから、何度も言っているように私は誰かや誰かを糾弾するつもりはありませ > ん。これは作品に関しても同様です。それとも PGG は上野さんの縄張で、そ > れを荒すと腹が立つんでしょうか？ あのぅ〜、お呼びでない奴が出てきて、お二人に余計に腹を立てられると困 るんですが、Emacs で知り合えた仲ですし、みんな仲良くやりましょうよ〜。 かく言うぼくもついカっ、ときて、大切な協力者に暴言を吐いてしまったこと が、二度、三度とありますが、腹立てて得した記憶がありません (未だに夜中 になると後悔することも... (;_;) ← 懺悔の涙)。 上野さんと守岡さんが言い争っている時間がもったいないと思います (Emacs 界の損失である!、絶対!)。 -- 中島幹夫 http://www.asahi-net.or.jp/~gy2m-nkjm/ From ueno ＠ bug.org Wed Dec 27 00:45:36 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 27 Dec 2000 00:45:36 +0900 Subject: binary-start-process In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "26 Dec 2000 17:47:40 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> Message-ID: <871yuvfaov.fsf@gg.bug.org> とりあえず、本題に関しては、 (1) pgg-messages-coding-system は defvar でこっそり定義する。 (2) mime-mailcap-method-messages-coding-system を導入。 という 2 点で合意したつもりです。 ;; (2) は、汚いものを入れたことを守岡さんに忘れないで頂けるよう、願いを込めて。 ;; 以下、情報量はありませんので、無視してください。 >>>>> In [emacs-mime-ja : No.00785] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> ;; むしろ、私が密かに願っていたのは、pgg で使用するより良い言語 守岡> ;; 環境に関する枠組を汎用的な形で上野さんが作ってくれることだっ 守岡> ;; たんですが、これはないものねだりと言わざるを得ないでしょう。 Daiki> 最初からそう言うべきでしょう。 守岡> そうですね。でも、多分、私自身が良く判ってなかったのでしょう。無論、こ 守岡> れは救いがたい私の問題です。 Daiki> 巧妙に犯人を PGG に押しつけることで、僕に仕事を回そうとしたその Daiki> 態度に、とても腹を立てています。 守岡> だから、何度も言っているように私は誰かや誰かを糾弾するつもりはありませ 守岡> ん。これは作品に関しても同様です。それとも PGG は上野さんの縄張で、そ 守岡> れを荒すと腹が立つんでしょうか？ 無論、header に GPL と明記してある以上「荒らす」のは自由です。 しかしながら、今回のような API の変更を伴う荒らしかたには抵抗があります。 たとえ小さなものであれ、それが守岡さんや岡田さんのような大きな影響力を もつ方々の手によるものである以上、sasl.el の API のように、将来的に深刻な 問題となる可能性もあるでしょう。 また、個人的には、(受け売りですが) シンプルさというのはかなり重大な要素 だと考えています。 ;; 99% の柔軟性を保証する大規模なフレームワークと、90% の柔軟性のうえで ;; code size を小さくしたものと、どちらがより将来性があるかと問われれば、 ;; 答えは自明ではないでしょう。 ;; また、セキュリティなどの様々な外部要因からなる制約を考慮した場合に、 ;; プログラマは自ずと記述可能性を制限するのではないでしょうか。 ;; 界面をいたずらに肥大化させておくのは得策とは思えません。 将来的に language environment next generation のような新しい枠組が完成し た暁には、PGG の実装に pgg-*-coding-system を利用するかも知れません。 しかしながら、gettext により表示の振舞いが直交化された外部プログラムの呼 出しという横木に対し、coding-priority-list や modify-coding-system-alist を駆使するよりもスマートな設定法があみだされているかも知れません。 というわけで、今は入れたくはありませんでした。 守岡> ただ、確かに私は、誰かがやってくれるとうれしいので、上野さん以外にも、 守岡> やれそうな人だと思うとつい甘えたことを言ってしまうことが多いと思います。 守岡> で、これはたかりの一種で御不快に思われることは理解できます（でも、ここ 守岡> まで激烈な反応を返されたのは驚きですが）。この件に関しても謝罪します。 きっと甘えかたに問題があったのではないでしょうか。 ;; 気まぐれプログラマなので、人に騙されて実装することほど嫌なことはありません。 -- Daiki Ueno From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 28 14:06:57 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 28 Dec 2000 14:06:57 +0900 Subject: [cmail 9514] FLIM 1.14 and SEMI 1.14 In-Reply-To: Taiji.Can@atesoft.advantest.co.jp's message of "Fri, 22 Dec 2000 16:29:16 +0900" References: <7083-Thu21Dec2000112045+0900-yutopia@t3.rim.or.jp> <889-Thu21Dec2000112937+0900-yutopia@t3.rim.or.jp> Message-ID: >>>>> [apel-ja : No.00498] にて >>>>> “菅さん”= Taiji.Can ＠ atesoft.advantest.co.jp さま曰く: 菅さん> > APEL-ja で話題になっていたように、APEL の mcharset.el の不具 菅さん> > 合だったようです。修正してみたつもりなので、よろしければ CVS 菅さん> > 上の最新版をお試しください。 菅さん> apel の mcharset.el なんですが、このように変更されてしまうと、 菅さん> nemacs では find-coding-system が pces-nemacs.el には存在し 菅さん> ないので、初っ端で tm のコンパイルが失敗してしまいます。 すみませんでした。 良く考えたら mcharset.el では coding-system 型の存在を仮定してはいけな いはずで、また、default-mime-charset-for-write は mime-charset 型なの に find-coding-system を使ってたのはおかしかったと思います。 そういう訳で、mime-charset-p を作ってそれを使うようにしてみました。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 28 14:51:19 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 28 Dec 2000 14:51:19 +0900 Subject: broken mime-example In-Reply-To: OKAZAKI Tetsurou's message of "Mon, 25 Dec 2000 14:48:46 +0900" References: <87elzy90g9.fsf@gg.bug.org> <8666k9nj9d.wl@dolphin.be.to> Message-ID: >>>>> In [emacs-mime-ja : No.00773] >>>>> "岡崎さん" = OKAZAKI Tetsurou wrote: 岡崎さん> > > そもそも、該当の部分をmake時に読み込む必要はないですよね． 岡崎さん> > 具体的には、現在 mime-view の toplevel に書かれている、 岡崎さん> > mime-{preview|acting}-siguation-example-list の設定箇所を 岡崎さん> > (eval-after-load "mime-view" ...) で括って、semi-setup.el 岡崎さん> > に入れてしまえばどうかと思うのですが、如何でしょうか？ 岡崎さん> 私は賛成します。もちろん、byte-compile 時ではなく、実行時に 岡崎さん> のみ読み込む様にしても、error message に関しては 岡崎さん> [emacs-mime-ja 00681]と同様の変更をした方が良いと思います。 byte-compile 時ではなく、実行時にのみ読み込むようにした方が良いという ことに関しては賛成します。しかし、semi-setup なしでも MIME-View の基本 部分は動くようにしたいと思うので、(eval-after-load "mime-view" ...) で 括って semi-setup.el に入れるという方法は避けたいです。そういう訳で、 あまり美しくない方法かも知れませんが、 (eval-when-compile (setq mime-situation-examples-file nil) ;; to avoid to read situation-examples-file at compile time. ) というような code を入れてみました。 また、いずれにしても、実行時に error が生じないようにした方が良いのは 賛成なので、 と同様の修正を行いました。また、 situation-examples-file を読む部分を関数 mime-view-read-situation-examples-file としました。 いかがでしょうか？ -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ====================== Email: ====== From akr ＠ m17n.org Thu Dec 28 16:05:31 2000 From: akr ＠ m17n.org (Tanaka Akira) Date: 28 Dec 2000 16:05:31 +0900 Subject: =?ISO-2022-JP?B?GyRCJCIkTiQlIUEbKEI=?= f(^^;;; In-Reply-To: (NAKAJIMA Mikio's message of "Tue, 26 Dec 2000 21:23:14 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> Message-ID: In article , NAKAJIMA Mikio writes: > あのぅ〜、お呼びでない奴が出てきて、お二人に余計に腹を立てられると困 > るんですが、Emacs で知り合えた仲ですし、みんな仲良くやりましょうよ〜。 えーと、今回の件に関する私の見方を一つ。 IRC で守岡さんに議論をふっかけて問題意識を精製したところ、結局外部コマ ンドとの通信における文字化けを防ぐフレームワークが欲しいという要求が根 底にあることが判明しました。 (ということを私が認識したということです。もちろん。) (上野さんには議論をふっかけていないので、見方があまいかも知れません。) これは守岡さんの問題ないしは希望なわけですが、折しも作業中、PGG のとこ ろで gpg を呼び出すコードを発見し、そのコードが(おそらく無意識中にある 架空のフレームワークにそぐわないという理由で)上野さんに「PGG が gpg を 呼び出す時の coding-system を指定する変数を新設する」修正を要求しまし た。 さて、この時点で問題は PGG の API の汚染という形で上野さんの問題にもな ります。上野さんはなぜ gpg を呼び出すコードがまずいのかわかりません。 gpg は国際化されていて、環境変数 LANG (や LC_*)によって挙動を変えるた め、文字化けを確実に防ぐためには環境変数と coding-system を同期させる 必要がありますが、変数を新設するだけではそのような同期はできません。同 期させないなら modify-coding-system-alist で gpg 用の coding-system を 指定させればおなじ事ができます。今でもおなじことができるなら、なぜ冗長 な変数 - 余計な API - を入れる必要があるのか、というわけです。 そこで議論をするわけですが、例によって発散していきます。守岡さんの根底 には文字化けを防ぐフレームワークが欲しいということがあるわけで、フレー ムワークに関する話にかたよりがちです。しかし上野さんはそれには興味が薄 く、フレームワーク自体をを自分ではじめから作ってまで文字化けを完全に防 ごうとは思いません。そして、language environment を使って、coding system を制御するというのはフレームワークに関する守岡さんの構想なので すが、悲しいかな現時点では language environment はそこまでの表現力があ りません。にもかかわらずフレームワークに関する説明も無しに 「`set-language-environment' and/or 変数 `current-language-environment' と同期する形で適切に PGG の表示を設定す ることは可能でしょうか？」などと書くので、language environment の改善 やフレームワーク自体の設計・実装を求められていると上野さんが感じて白熱 していきます。 また、守岡さんは emacs の視点からものを見ているので、emacs の外のコマ ンドがどんなものであろうが elisp で制御可能であることを求めます。しか し、上野さんは(gpg を含む)正しく国際化されたコマンドという視点からもの を見て、なんでも制御可能にするのは、失敗する可能性を増やすだけなのでは ないかという可能性を考えます。そして、それぞれ相手に前提や視点を伝える こと、相手の前提や視点を把握することに失敗し、議論はさらに発散・白熱し ていきます。 最終的に、上野さんは mime-mailcap-method-messages-coding-system の導入 (と defvar 化)によって、守岡さんに同種の気持ち悪さを感じてもらえるよう 願いつつ、議論を終わらせたわけですが、おそらく、守岡さんは elisp で全 部制御するのが希望なので、制御方法が増えるのはいつでも歓迎なのではない か、と思います。 と、いうのが私の見方です。 今回の件についていえばネタを出したのは守岡さんなので、守岡さん自身の問 題意識を把握・説明しなかった、というのがおそらく最初の原因です。 議論が始まる前に問題が把握されていないこと自身は悪いことではありません。 というか、これは一般にどうしようもないことです。重要なのは問題を把握す る方向で議論を行なうということですが... とりあえずワインバーグの本あた りを読むというのがいいのかも知れません。 (と、きのう守岡さんに改善案を尋ねられたのでひとつ提案しておく。) -- [田中 哲][たなか あきら][Tanaka Akira] 「ああ、それは大丈夫だよぉ。カイロを持って行くもぉん?」 (気象精霊記2 爆弾気分の低気圧, 清水文化) From akr ＠ m17n.org Thu Dec 28 16:37:07 2000 From: akr ＠ m17n.org (Tanaka Akira) Date: 28 Dec 2000 16:37:07 +0900 Subject: =?ISO-2022-JP?B?GyRCJCIkTiQlIUEbKEI=?= f(^^;;; In-Reply-To: (Tanaka Akira's message of "28 Dec 2000 16:05:31 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> Message-ID: In article , Tanaka Akira writes: > IRC で守岡さんに議論をふっかけて問題意識を精製したところ、結局外部コマ > ンドとの通信における文字化けを防ぐフレームワークが欲しいという要求が根 > 底にあることが判明しました。 すこし書き忘れました。 ここで、このフレームワークは(LANG によって挙動を変えるような)正しい国 際化コマンドだけでなく、ad-hoc な日本語化コマンドなど怪しい挙動をする コマンドも扱えるものを考えているようです。 そして、modify-coding-system-alist は coding-system をコマンド名で設定 するのですが、これはたしかに怪しいコマンドを扱うには不足です。コマンド 名以外の文脈に応じて変える必要があります。 (例えば、意味があるかどうかはともかくとして、nkf -Se を文字化けせずに 呼ぶには coding-system-for-read を euc-jp, coding-system-for-write を sjis にしなければならないでしょうが、modify-coding-system-alist ではそ のような指定はできない。) ただ gpg は正しく国際化されているため、このようなフレームワークは PGG に使うには少々 overspec です。正しく国際化されているものなら locale と coding-system の整合をとるだけで話は済みます。しかし、ひとつのフレーム ワークで扱うにはある程度共通の API で coding system を制御可能である必 要があります。 そのため、少し冗長にも思える API を PGG に入れることを要求した、という のが真相のようです。 こういう背景、問題意識、意図が早期に示されればこれほど白熱することはな かったんじゃないかなぁ、と思うんですがねぇ。 あるいは、modify-coding-system-alist ではなぜ駄目なのかという質問に対 して、歴史的な話ではなく技術的にうまくいかない場合を提示するとか、問題 を把握できたかもしれないきっかけはいくつもあったのにと思えてなりません。 -- [田中 哲][たなか あきら][Tanaka Akira] 「ああ、それは大丈夫だよぉ。カイロを持って行くもぉん?」 (気象精霊記2 爆弾気分の低気圧, 清水文化) From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Thu Dec 28 18:05:35 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 28 Dec 2000 18:05:35 +0900 Subject: SEMI 1.14.3 =?ISO-2022-JP?B?KBskQjVtJU5DKxsoQik=?= Message-ID: [Status] alpha [Required Environment] APEL: 9.22 (or later) FLIM: 1.14.2 [Changes] 2000-12-28 MORIOKA Tomohiko * SEMI: Version 1.14.3 (Ushinoya) released. * mime-view.el (mime-view-read-situation-examples-file): Don't try to read situation-examples-file is it is nil. (mime-situation-examples-file): Avoid to read situation-examples-file at compile time. 2000-12-28 MORIOKA Tomohiko * mime-view.el (mime-view-read-situation-examples-file): Display warning. [cf. ] 2000-12-27 MORIOKA Tomohiko * mime-view.el (mime-view-mailcap-files): New user option. (mime-view-read-mailcap-files): Renamed from `mime-view-read-mailcap'; read `mime-view-mailcap-files'. * mime-view.el (mime-view-read-situation-examples-file): New function; don't occur error. (mime-view-read-mailcap): New function. 2000-12-27 MORIOKA Tomohiko * mime-play.el (mime-play-messages-coding-system): Renamed from `mime-mailcap-method-messages-coding-system'. * pgg-def.el (pgg-messages-coding-system): Change default value to nil. 2000-12-27 MORIOKA Tomohiko * mime-play.el (mime-activate-mailcap-method): Fix typo. 2000-12-26 Daiki Ueno * mime-play.el (mime-mailcap-method-messages-coding-system): New variable. (mime-activate-mailcap-method): Use it. 2000-12-26 Daiki Ueno * pgg-def.el (pgg-messages-coding-system): Use `defvar' to define. * pgg-pgp.el (pgg-pgp-messages-coding-system): Abolish. (pgg-pgp-process-region): Use `binary-funcall' instead of `binary-to-text-funcall'. * pgg-pgp5.el (pgg-pgp5-messages-coding-system): Abolish. (pgg-pgp5-process-region): Use `binary-funcall' instead of `binary-to-text-funcall'. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/semi/semi-1.14-for-flim-1.14/ -------------- next part -------------- -- tomo. From ueno ＠ bug.org Thu Dec 28 20:01:16 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 28 Dec 2000 20:01:16 +0900 Subject: =?ISO-2022-JP?B?GyRCJCIkTiQlIUEbKEI=?= f(^^;;; In-Reply-To: (Tanaka Akira's message of "28 Dec 2000 16:37:07 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> Message-ID: <87bstwrern.fsf@gg.bug.org> >>>>> In [emacs-mime-ja : No.00791] >>>>> Tanaka Akira wrote: 少し補足しますが、 > ここで、このフレームワークは(LANG によって挙動を変えるような)正しい国 > 際化コマンドだけでなく、ad-hoc な日本語化コマンドなど怪しい挙動をする > コマンドも扱えるものを考えているようです。 個人的には、この仮定が気になります。 外部コマンドは『人間』ではないので、 ・(Emacs 上の) application は外部コマンドに一定の界面を規定する。 ・期待した振舞いをしない application は使わない。 ・どうしてもその機能を使いたいのであれば shell script や LD_PRELOAD などを駆使して Emacs の外で wrap する。 ・それでもだめなら application 作者が、自分で満足のいく外部コマンドを書く。 という態度を貫いても良いではないか、というのが僕の主張です。 たとえば starttls や Liece の ltcp なども、結局 OpenSSL の s_client や tcp では満足できずに自前のコマンドを書くに至ったわけです。 ;; 根本的には、COM や Bonobo のような component を直接扱えるようになれば ;; 良いのですが。Meadow に期待。 とはいえ、mime-play-entity のような曖昧な実装では、呼ばれるコマンドおよ び、呼ばれかたも利用者である人間の手に委ねられているわけで、本来、 overspec なフレームワークはこの部分にこそ必要なのではないかと思います。 -- Daiki Ueno From ueno ＠ bug.org Thu Dec 28 20:24:17 2000 From: ueno ＠ bug.org (Daiki Ueno) Date: 28 Dec 2000 20:24:17 +0900 Subject: =?ISO-2022-JP?B?GyRCJCIkTiQlIUEbKEI=?= f(^^;;; In-Reply-To: <87bstwrern.fsf@gg.bug.org> (Daiki Ueno's message of "28 Dec 2000 20:01:16 +0900") References: <87hf3xn8k0.fsf@gg.bug.org> <87k88tklbq.fsf@gg.bug.org> <87itocy00t.fsf@gg.bug.org> <87ae9jg5k8.fsf@gg.bug.org> <87bstwrern.fsf@gg.bug.org> Message-ID: <878zp0rdpa.fsf@gg.bug.org> すみません、修正します。 >>>>> In [emacs-mime-ja : No.00793] >>>>> Daiki Ueno wrote: > ・期待した振舞いをしない application は使わない。 ・期待した振舞いをしない「外部コマンド」は使わない。 の間違いです。 > とはいえ、mime-play-entity のような曖昧な実装では、呼ばれるコマンドおよ > び、呼ばれかたも利用者である人間の手に委ねられているわけで、本来、 > overspec なフレームワークはこの部分にこそ必要なのではないかと思います。 「曖昧な実装」というのは責めているわけではなくて、mailcap 自体の定義 (RFC1524) が、このような性質を持つ以上いたしかたない、という程度の意味です。 -- Daiki Ueno