Reformatted excerpts from Eduardo Habkost's message of 2008-11-26: > I would even argue that adding the tags configured for both sources > should be the default, but I don't know if there are users relying on > the current behavior, today. What do you think?
Actually, I think you're right. I don't know that there's a reason, at least during normal operation, to discard previous index state. Can you try the attached patch and see if it fixes the problem? > But as an user, I expect that a message appearing on both a non-inbox > source and an inbox source would get into the inbox. The problem would > be handling a message appearing on an inbox source after the user have > archived it. On this case, the user may expect the message to not > appear on the inbox again (I am not sure what would be more > intuitive). Well, it's an ambiguous situation, and I'm generally happy in ambiguous situations to take the simplest (to implement!) approach, which in this case is to pop it back into the inbox. > Additionally, I think it would be nice if sup were aware of when the > message appears multiple times on the sources, instead of rewriting > the source and offset fields. Most times the user doesn't need to be > aware there are multiple versions of a message, but when checking > message headers or other small details of messages coming from > different paths, it would be useful to have both versions available. I think I agree. STS (the apocryphal new version of Sup) probably won't canonicalize by message id like Sup does. -- William <[EMAIL PROTECTED]>
0001-for-duplicate-messages-merge-labels-rather-than-dis.patch
Description: Binary data
_______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
