From: Raphaël <rap...@gm...> - 2012-10-24 14:53:53
|
Hi, first of all I just pushed: * your mutt-groups version * merge feature * remove duplicates feature other reviews will be appreciated though. On Wed, Oct 17, 2012 at 11:00:37PM +0200, Fabio Zanini wrote: > 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 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 absolutely disagree with the "1 entry per line" assumption. Let's put apart multiple names and parsing issues and concentrate on the meaning of multiple email addresses: If you happen to have multiple <addresses> in a mutt alias line then these addresses represent different people. We rarely send a message to the multiple addresses of the same guy and even more rarely create an alias for such a task. Multiple addresses in a mutt alias line refer to multiple people in 99.9% use-case, isn't ? > 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. We may either ignore additional addresses, or we may want to create multiple entries, but the association of all addresses to the same guy ("nick") would be wrong most of the time. > > 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 > > [...] > 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. I do agree here: don't try the impossible if no angular bracket and do less or even no warning at all. > > 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. I'd prefer parsing mutt's alias lines the way there are written by users (alias containing multiple addresses meaning multiple people) and postpone discussions about the code itself. > Sumarizing my suggestions: > - one alias, one name, one abook entry (several email addresses possible) NAK (my patch is archived on the ML for the time this is reconsidered :)) > - email = angular brackets ok > - the rest is ignored silently (if accepted by mutt) or reported ok best regards! |