[PATCH] fix for lisp/mail/mail-extr.el / mail-lib/mail-extr.el

[PATCH] fix for lisp/mail/mail-extr.el / mail-lib/mail-extr.el

[Simon Josefsson]

Several people have been surprised by the result from
`mail-extract-address-component' when used like this:

(mail-extract-address-components "lawrence <foo@bar.com>")
    => (nil "foo@bar.com")

This is because `mail-extr-ignore-single-names' defaults to t.
Default to t might have been a good idea at some point in time, but I
don't think it makes sense today.  This patch changes the default and
fixes the m-e-a-c doc string somewhat.

If noone objects I can commit this.

2002-09-24  Simon Josefsson  <jas@extundo.com>

	* mail/mail-extr.el (mail-extr-ignore-single-names): Change default.
	(mail-extract-address-components): Doc fix.

Index: mail-extr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/mail-extr.el,v
retrieving revision 1.38
diff -u -p -u -w -r1.38 mail-extr.el
--- mail-extr.el	9 Jul 2002 10:06:17 -0000	1.38
+++ mail-extr.el	24 Sep 2002 21:35:37 -0000
@@ -226,7 +226,7 @@ we will assume that \"John Q. Smith\" is
   :type 'boolean
   :group 'mail-extr)
 
-(defcustom mail-extr-ignore-single-names t
+(defcustom mail-extr-ignore-single-names nil
   "*Whether to ignore a name that is just a single word.
 If true, then when we see an address like \"Idiot <dumb@stupid.com>\"
 we will act as though we couldn't find a full name in the address."
@@ -710,7 +710,8 @@ Unless NO-REPLACE is true, at each of th
 (defun mail-extract-address-components (address &optional all)
   "Given an RFC-822 address ADDRESS, extract full name and canonical address.
 Returns a list of the form (FULL-NAME CANONICAL-ADDRESS).
-If no name can be extracted, FULL-NAME will be nil.
+If no name can be extracted, FULL-NAME will be nil.  Also see
+`mail-extr-ignore-single-names'.
 
 If the optional argument ALL is non-nil, then ADDRESS can contain zero
 or more recipients, separated by commas, and we return a list of
@@ -719,8 +720,8 @@ each recipient.  If ALL is nil, then if 
 one recipients, all but the first is ignored.
 
 ADDRESS may be a string or a buffer.  If it is a buffer, the visible
- (narrowed) portion of the buffer will be interpreted as the address.
- (This feature exists so that the clever caller might be able to avoid
+\(narrowed) portion of the buffer will be interpreted as the address.
+\(This feature exists so that the clever caller might be able to avoid
  consing a string.)"
   (let ((canonicalization-buffer (get-buffer-create " *canonical address*"))
 	(extraction-buffer (get-buffer-create " *extract address components*"))

[Q] fix for lisp/mail/mail-extr.el / mail-lib/mail-extr.el

[Stephen J. Turnbull]

QUERY

>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:

    Simon> Default to t might have been a good idea at some point in
    Simon> time, but I don't think it makes sense today.  This patch
    Simon> changes the default and fixes the m-e-a-c doc string
    Simon> somewhat.

Please ask the BBDB guys and the MUA authors whether they depend on
this behavior, or at least give them a courtesy ping as you commit.

BBDB especially seems a likely candidate for changing the priority of
attribution strings according to what m-e-a-c returns.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

[COMMIT] Re: fix for lisp/mail/mail-extr.el / mail-lib/mail-extr.el

[Simon Josefsson]

BBDB and VM authors was OK with it, I'll fix Gnus if necessary.  I
have committed it to (X)Emacs CVS.

(In case some news admin is reading this: the bug-gnu-emacs news
gateway is down again.)

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> QUERY
>
>>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:
>
>     Simon> Default to t might have been a good idea at some point in
>     Simon> time, but I don't think it makes sense today.  This patch
>     Simon> changes the default and fixes the m-e-a-c doc string
>     Simon> somewhat.
>
> Please ask the BBDB guys and the MUA authors whether they depend on
> this behavior, or at least give them a courtesy ping as you commit.
>
> BBDB especially seems a likely candidate for changing the priority of
> attribution strings according to what m-e-a-c returns.
>
> -- 
> Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
>  My nostalgia for Icon makes me forget about any of the bad things.  I don't
> have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py