Re: [Abook-devel] patch: mutt groups

[Fabio Z. <fab...@fa...>]

Dear Raphael, dear all,

On Mon, Oct 15, 2012 at 12:41:31PM +0200, Raphaël wrote:
> Thinking a bit more about this I found misleading that we only handle 1
> address and silently drop other possible cases like: 
> > alias -group XX nick name surname addr@ess1, name2 addr@ess2
> or even
> > alias nick <addr@ess1>, <addr@ess2>
> 
> I don't know how used the syntax is but the attached patch (applies on top of
> yours) handles such cases where a -group lines has multiple associated
> addresses.

I strongly opppose parsing of the first form. I think one line should
correspond to one alias, to one name. We should complain via a warning
or error message otherwise.

I agree that the second form, i.e. multiple email addresses on the same
line, should be parsed. Since email are list items in abook already,
this should be easy enough.

> But I (partly) wonder about the way to handle:
> > alias -group XX nick name surname add@ress, some string surname2 name2 <addr@ess2>
> which provides addr@ess2 as part of the "nick" alias.
> ( addr@ess2 must be <delimited> for mutt to work )

I would be strict on this, lest we embark in a horrible heuristic
parsing endevour. I would require that an address always  be in angular
brackets, and that's it. We do not parse spelling mistakes.

> The second question is about what to do when we don't parse, eg:
> > alias alias1 alias2
> is valid for mutt but not for abook (even if searching the db were
> reasonable, we couldn't store 2 aliases for 1 item).
> The current behavior is email=name=alias2 + nick=alias1 which is
> obviously wrong.
> Should we print a warning and/or skip the item or just fail ?
> [ when mutt can't parse it warns then ask whether to continue or not,
> but I don't find this behavior useful for abook ]

I would just silently skip the line. Since these lines are likely to be
found in mutt alias files, it is unacceptable to issue warnings all the
time; on the other hand, these lines have no meaning for abook, so we
cannot possibly parse them in.

> About the current patch:

Thanks for writing it. I haven't tested it yet, but would like to hear
your feedback on the parsing issues above first. I would also try to
save the one-line-is-one-item correspondance, which keeps our code clean
and structured.

Sumarizing my suggestions:
- one alias, one name, one abook entry (several email addresses possible)
- email = angular brackets
- the rest is ignored silently (if accepted by mutt) or reported

Cheers,
Fabio