supercite.el: sc-get-address/sc-attribs-extract-namestring
The following is for XEmacs 21.4.10 (the current Debian package) with
supercite.el with version details:
;; Version: 3.1
;; Last Modified: Fri Aug 4 15:01:46 CEST 2000
;; supercite.el revision: 3.55-x
;; Copyright (C) 1993 Barry A. Warsaw
There's a mismatch in logic between sc-get-address and
sc-attribs-extract-namestring in supercite.el. I receive e-mail from
a someone who's From: address looks like:
Doe John x1234 <john(a)doe.a.deer>
Yep, it's weird, but it should work (and does under GNU Emacs 21.2).
So, I run the following little experiment:
ELISP> (setq yip "Doe John x1234 <john(a)doe.a.deer>")
"Doe John x1234 <john(a)doe.a.deer>"
ELISP> (sc-attribs-extract-namestring yip)
"Doe John"
ELISP> (sc-get-address yip (sc-attribs-extract-namestring yip))
"x1234 <john(a)doe.a.deer>"
and this is what is associated with "sc-from-address" (which, in turn,
is looked up in my BBDB to try and find the attribution, and fails)...
Possible solutions:
* Import the definition of sc-attribs-extract-namestring from GNU
Emacs 21.2, since it returns the full namestring:
ELISP> (sc-attribs-extract-namestring yip)
"Doe John x1234"
However, this still seems to leave room for weirdness.
* Change sc-get-address to try harder to find a proper address.
Currently it takes the portion of from after the provided
namestring and checks if that is a string enclosed in <brackets>:
(let ((address (substring from (match-end 0) eos)))
(if (and (= (aref address 0) ?<)
(= (aref address (1- (length address))) ?>))
(substring address 1 (1- (length address)))
address))
Alternatively, it could use sc-attribs-<>-addresses to try and find
a substring enclosed in <brackets>:
(let* ((address (substring from (match-end 0) eos))
(yip (sc-attribs-<>-addresses address)))
(or yip address))
That seems to work nicely...
ELISP> (sc-get-address yip (sc-attribs-extract-namestring yip))
"john(a)doe.a.dear"
peace & happiness,
martin