Wrappers for gnus-extract-address-components (was: [...] gnus-util.el)

Wrappers for gnus-extract-address-components (was: [...] gnus-util.el)

[Reiner Steib]

On Wed, May 07 2008, Ted Zlatanov on ding-patches:

> * gnus-util.el (gnus-extract-address-component-name)
> (gnus-extract-address-component-email): Convenience functions around
> `gnus-extract-address-components'.

I doubt that we need these wrappers.  Just using `car' and `cadr' is
sufficiently convenient for me.

> +(defun gnus-extract-address-component-name (from)
> +  "Extract name from a From header.
> +Uses `gnus-extract-address-components'."
> +  (nth 0 (gnus-extract-address-components from)))
> +
> +(defun gnus-extract-address-component-email (from)
> +  "Extract e-mail address from a From header.
> +Uses `gnus-extract-address-components'."
> +  (nth 1 (gnus-extract-address-components from)))

When introducing such wrapper, we might use (funcall
gnus-extract-address-components ...) instead.

And the names should be something more simple like `...-extract-name'
and `...-extract-address'.  As they should be usable in `message.el'
as well, we should put them in `gmm-utils.el' to avoid code like this:

     (funcall (if (boundp gnus-extract-address-components)
		  gnus-extract-address-components
		'mail-extract-address-components)
	      from)

Or, `gnus-extract-address-components' could use an optional argument,
which can have the values 'name or 'address.

Opinions?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Wrappers for gnus-extract-address-components

[Ted Zlatanov]

(please note my <Teodor.Zlatanov@divine.com> address still shows up in
CVS commits but has not been otherwise active in 7 years)

On Wed, 07 May 2008 20:08:49 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Wed, May 07 2008, Ted Zlatanov on ding-patches:
>> * gnus-util.el (gnus-extract-address-component-name)
>> (gnus-extract-address-component-email): Convenience functions around
>> `gnus-extract-address-components'.

RS> I doubt that we need these wrappers.  Just using `car' and `cadr' is
RS> sufficiently convenient for me.

IMO, car/cadr used in this fashion are annoying in code because you have
to know the data structure (from comments or reading the source
further).  It's cleaner for someone reading the code to see

(gnus-extract-address-component-email sender)

than

(cadr (gnus-extract-address-components sender))

I think it's nice to have these, obviously, but if you don't like them
then just remove them and adjust gnus-registry.el accordingly.  OTOH if
you decide they are OK to stay, I can look through all the Gnus code to
see if I should rewrite anything to use the wrappers.

>> +(defun gnus-extract-address-component-name (from)
>> +  "Extract name from a From header.
>> +Uses `gnus-extract-address-components'."
>> +  (nth 0 (gnus-extract-address-components from)))
>> +
>> +(defun gnus-extract-address-component-email (from)
>> +  "Extract e-mail address from a From header.
>> +Uses `gnus-extract-address-components'."
>> +  (nth 1 (gnus-extract-address-components from)))

RS> When introducing such wrapper, we might use (funcall
RS> gnus-extract-address-components ...) instead.
RS> And the names should be something more simple like `...-extract-name'
RS> and `...-extract-address'.  As they should be usable in `message.el'
RS> as well, we should put them in `gmm-utils.el' to avoid code like this:

RS>      (funcall (if (boundp gnus-extract-address-components)
RS> 		  gnus-extract-address-components
RS> 		'mail-extract-address-components)
RS> 	      from)

mail-extract-address-components and gnus-extract-address-components can
return different things, that's why I didn't merge them in the wrapper.
If you think it's useful, feel free to make the change.  I don't have an
opinion.

The function name doesn't matter much to me, so renaming to remove
-component from the name is fine.  But I won't do it until you decide if
the wrappers are staying.

RS> Or, `gnus-extract-address-components' could use an optional argument,
RS> which can have the values 'name or 'address.

I think it's a very common thing to require the address or name from a
From header, so these functions should not be hidden behind an optional
argument.  I realize it's not good to clutter the namespace, but these
functions are pretty basic for Gnus since it's a MUA.

Also, gnus-extract-address-components returns a list, and with the
optional argument it wouldn't, which is unnecessarily inconsistent.  You
could make it always return a list but then there's no point to have the
wrapper.

Ted

Mail address in the commit lists (was: Wrappers for gnus-extract-address-components)

[Reiner Steib]

On Wed, May 07 2008, Ted Zlatanov <tzz@lifelogs.com> wrote:

> (please note my <Teodor.Zlatanov@divine.com> address still shows up in
> CVS commits but has not been otherwise active in 7 years)

I didn't notice that it's a different address.  IIRC, Lars can change
the address.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Mail address in the commit lists (was: Wrappers for gnus-extract-address-components)

[Reiner Steib]

On Wed, May 07 2008, Ted Zlatanov <tzz@lifelogs.com> wrote:

> (please note my <Teodor.Zlatanov@divine.com> address still shows up in
> CVS commits but has not been otherwise active in 7 years)

I didn't notice that it's a different address.  IIRC, Lars can change
the address.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Mail address in the commit lists

[Ted Zlatanov]

On Thu, 08 May 2008 00:19:16 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Wed, May 07 2008, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> (please note my <Teodor.Zlatanov@divine.com> address still shows up in
>> CVS commits but has not been otherwise active in 7 years)

RS> I didn't notice that it's a different address.  IIRC, Lars can change
RS> the address.

I asked and he said he'd do it a while ago.  Maybe it got lost in the
shuffle.

Ted