Re: supercite.el: sc-get-address/sc-attribs-extract-namestring

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&gt; then `gnus-extract-address-components' gets it horribly wrong, but `mail-extract-address-components' gets it right. If I start maintaining any of this code I'm going to take the novel approach of putting together some regression tests... :-) Simon> I don't think so -- having a real parser would allow you to Simon> say that you want to look at the first comment after an Simon> addr-spec. A function could try all the standard ways to Simon> put the full name in a header line and return it to the Simon> caller. OK, fair enough. 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. 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... :-) peace & happiness, martin