山岡> XEmacs 21.1.16 + UTF-2000 (+ nkf) で不可解な現象が起きるのですが、 山岡> もしお心当たりがありましたら教えて下さい。 山岡> 以下は中治さんへの返信を gnus でしようとしたときの backtrace です。 山岡> Signaling: (wrong-type-argument number-char-or-marker-p (29)) 山岡> std11-lexical-analyze("なかじ <nakaji(a)tutrp.tut.ac.jp&gt;&quot;) 山岡> std11-parse-address-string("なかじ <nakaji(a)tutrp.tut.ac.jp&gt;&quot;) 山岡> std11-extract-address-components("なかじ <nakaji(a)tutrp.tut.ac.jp&gt;&quot;) 山岡> message-make-in-reply-to() 山岡> message-generate-headers((From Subject Date (optional . In-Reply-To) Message-ID Lines (optional . User-Agent))) 山岡> message-send-mail(nil) 山岡> message-send-via-mail(nil) 山岡> message-send(nil) 山岡> message-send-and-exit(nil) 山岡> call-interactively(message-send-and-exit) 山岡> このエラーが起きる直接の原因は、関数 std11-lexical-analyze にある 山岡> (おそらく) バグのせいだと思うので、最後にパッチを添付しておきます。 山岡> しかし普通に使っている場合はここに差し掛かることは無いようで、原因 山岡> は他にあるような気がします。と言うのは *scratch* で以下を eval し 山岡> ても問題なく動作するからです。 これが、 守岡> [既知の問題点] 守岡> --with-utf-2000 を指定した場合において、ある特定の状況（詳細は不明） 守岡> で、（非 ASCII ?）文字列に対する正規表現の matching が正常な結果を 守岡> 返さない場合がある です。(^_^;;; 山岡> (std11-lexical-analyze "なかじ <nakaji(a)tutrp.tut.ac.jp&gt;&quot;) 山岡> 実際に std11-parse-address-string に渡る文字列がこれとは違うのかと思っ 山岡> て調べてみましたがそうでもありません。 山岡> [2 std11.el.diff <application/octet-stream (7bit)>] 山岡> --- std11.el~ Mon May 31 19:29:52 1999 山岡> +++ std11.el Tue Jun 22 13:35:18 1999 山岡> ＠＠ -398,7 +398,7 ＠＠ 山岡> (null (setq r (funcall func string start)))) 山岡> (setq rest (cdr rest))) 山岡> (or r 山岡> - (list (cons 'error (substring string start)) (1+ len))) 山岡> + (cons (cons 'error (substring string start)) (1+ len))) 山岡> )) 山岡> (setq dest (cons (car ret) dest) 山岡> start (cdr ret)) これは本来 typo と言って良いですが、一方で、これが問題が起こるということ は異常事態なので、こういう問題を発見するという観点では、むしろ、error を 起こす方が良いかも知れません。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo(a)etl.go.xn--jp&gt;-8n7c ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━