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

Martin> [OK, I've finished annoying Joe Wells... By the way, is Martin> there an easy Martin> way of finding out who the current XEmacs maintainer for Martin> something is?] Hi Martin, on a package level to get the info by XEmacs <= 21.1 Options->Manage Packages->Add Download Site->xemacs.org Options->Manage Packages->List & Install XEmacs >= 21.4 Tools->Packages->Add Download Site->xemacs.org Tools->Packages->List & Install then typing i for information on the package under point. Hope this helps, Adrian Simon> Do you mean how to use it? Like I said, call it with ASCII Simon> only strings. mail-extr.el seems to have been designed for Simon> parsing name and addressess from RFC 822 headers (see the Simon> first line of the file, for instance), and mail headers are Simon> ASCII only. I guess the problems comes when it is used in Simon> non-RFC822 situations, where the full mail address includes Simon> non-ASCII, but mail-extr.el was not designed to be used for Simon> that from what I can tell, and it does a poor job of it in Simon> practice too (demonstrated by the buggy snippet in this Simon> thread). Martin> OK, I have a really naive question (since I've always taken the Martin> non-ASCII stuff for granted, since I only have an ASCII name :-): Martin> In general, is there are simple way of getting the contents of the Martin> original 7-bit mail header without rendering it? Martin> Surely that's the right way of handling it... Martin> In the case of VM, it looks like the headers need to be taken from the Martin> INBOX buffer instead of the "INBOX Presentation" buffer (substitute Martin> appropriate folder names where necessary). That looks to be an easy Martin> way of getting the ASCII version (and see comment below). Martin> However, mail-extr.el still doesn't work adequately on the unrendered Martin> version: ELISP> (mail-extract-address-components "Ville =?iso-8859-1?q?Skytt=E4?= <scop(a)xemacs.org&gt;&quot;) Martin> ("Ville" &quot;scop(a)xemacs.org&quot;) Martin> :-( Martin> [Suddenly Ville joins people such as Prince and Madonna... :-] Simon> As for implementing this properly, I think it would be nice Simon> to have a higher-level API that handled mail addresses with Simon> non-ASCII content. Perhaps this new API should even Simon> replace the current `mail-extract-address-components' entry Simon> point. Of course, that effect could be simulated by Simon> enhancing the current mail-extr.el but looking at the code Simon> I doubt it will be a pleasant experience. Martin> OK, as you said, mail headers are ASCII. Once they are rendered using Martin> whatever encoding they might specify, it is probably too late to try Martin> to do something clever to try and handle them as ASCII, because the Martin> rendering isn't necessarily reversible (I guess). Martin> Hmmm... maybe we're saying the same thing? Simon> (Another rant is that mail-extr.el doesn't implement a Simon> correct RFC(2)822 parser, but rather a heuristic parser Simon> improved over time. In fact, emacs doesn't have a correct Simon> RFC 2822 parser anywhere, which is a shame.) Martin> I think that would be nice, but there is (at least) one interesting Martin> problem with using a proper RFC2822 parser. My reading of it tells me Martin> that in Martin> Simon Josefsson <jas(a)extundo.com&gt; Martin> the "Simon Josefsson" part is a display-name, which is useful for our Martin> purposes. However, in Martin> jas(a)extundo.com (Simon Josefsson) Martin> the "Simon Josefsson" part is a comment that isn't a separate synactic Martin> (and, therefore, semantic) entity. Martin> Writing a formal RFC2822 parser might actually gives us less than what Martin> we need... Martin> Another problem (separate from RFC2822 issues) is that things like Martin> BBDB store the rendered version, so if we start pulling our unrendered Martin> chunks of headers, we'd have to render them before comparing... Martin> Maybe it is a case of incrementally fixing the glitches... or coming Martin> up with something really clever. I think the really clever idea is to Martin> always deal with (and store) unrendered ASCII chunks and be careful Martin> when comparing them... but that sounds like a lot of work and involves Martin> getting a lot of people to agree... Martin> peace & happiness, Martin> martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/