From: Raphaël <rap...@gm...> - 2012-10-15 10:41:46
|
On Mon, Sep 24, 2012 at 08:49:28AM +0200, Fabio wrote: > On Sun, Sep 23, 2012 at 11:39:50PM +0200, Raphaël wrote: > > But I got more mixed results on the input filter side (unrelated to the > > use of -addr): > > Note that I only parse the -group option of the mutt "alias" file, i.e. > something like: > > alias -group XX nick name surname address I can now confirm that it works well for such patterns. 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. 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 ) While defining two distinct aliases in the same line is not permitted (nor really useful) for mutt, should we play nicer at this ? we can: [1] store the same alias ("nick") for all items in the line [2] not store any alias except for the first item [3] try to extract an alias from the string preceding each email (except the first one where alias is explicit). Unless I missed something, [1] is useless and confusing for users. [2] is safe, simple and matches muttrc(5) documentation [3] may be smart but not fool-proof as we can't say for sure that "some" is the NICK to give to "name2" or a part of its full-name 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 ] About the current patch: That fact that multiple items may be created forced me to bring mutt_read_line() code inside mutt_parse_file(). I replaced some broken and disabled code from mutt_fix_quoting(), ending with a reduced code size (hopefully more readable too) (as a bonus it now works for non-terminated lines and should not segfault anymore in some edge-cases) The current version sets the nick for the 1st item only (above solution [2]) see also: $ ./abook --convert --informat mutt --outformat abook < testcase.muttrc |\ ./abook --convert --informat abook --outformat mutt any thoughts appreciated regards |