Re: supercite.el: sc-get-address/sc-attribs-extract-namestring
"Martin Schwenke" <martin(a)meltin.net> writes:
>>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> I think so. OTOH, if you do have the rendered full mail
Simon> address, you should be able to use some elisp package to
Simon> get the mail address only.
Simon> `gnus-extract-address-components' does this, but perhaps
Simon> you don't want to depend on Gnus. You could copy the code
Simon> (it is short), but then you will have to keep it in sync
Simon> whenever it is updated, so it is probably not such a good
Simon> idea.
`gnus-extract-address-components' is a little too simplistic. If I
try to use it to parse something (reasonably stupid, but apparently
allowed by RFC2882, and the sort of thing that some people might
write) like
"John Doe (John＠Home)" <john(a)doe.a.deer>
then `gnus-extract-address-components' gets it horribly wrong, but
`mail-extract-address-components' gets it right.
Ouch.
If I start maintaining any of this code I'm going to take the
novel
approach of putting together some regression tests... :-)
A regression test suite would be a very useful start in getting a new
implementation working. Maybe you can check with the mail-extr.el
authors if they still have the test-case mentioned below?
;; We have an extensive test-case collection of funny addresses if you want to
;; work with the code. Developing this code requires frequent testing to
;; make sure you're not breaking functionality. The test cases aren't included
;; because they are over 100K.
Simon> I dunno, there doesn't seem to be a simple
solution.
Simon> Dealing with and storing unrendered ASCII chunks has the
Simon> same problems, the same name can be expressed in many ways.
Yep. The only problem it solves is that the unrendered ASCII chunks
are well defined (in RFC2822) - you don't have to mess with character
set nastiness.
Until you want to compare two ASCII chunks for equality, then you need
to decode it and possibly transcode and even decompose characters
before comparing the strings.
Sadly, I think incremental fixes to the existing code are going to
be
the way forward although, if I get a rainy weekend, I might try to
write a full RFC2882 address parser... :-)
Good luck. :-)