Re: Mail to self
(sorry for sending twice, had the wrong From: line once again, hopefully I have fixed my client by adding this address to `user.other_email` now… need some time to adapt, sorry) Hi Gregor, Gregor Zattler writes: > For me, when I filtered emails in several folders and read them > with mutt (1) it was the other way around: I wished for the > possibility to mark them as read in all folders if read in one. This isn't incompatible, and I'm not wishing that notmuch stop marking as read per-message. However, I *am* wishing that when some other tool marked one of the message files as read and not the other, notmuch takes the safe route of marking the overall message as unread in its database. > But why would you tag a message (as opposed to a file) as > "unread" because it's a duplicate? Because usual folder-based applications display an unread marker with the number of unread messages near the folder, and this is a useless visual disturbance for the people for whom I administer the mail server. > If it's somehow important to you to know that a certain email > your read via notmuch is a duplicate, why not tag it as > "duplicate" instead? This is not a problem in notmuch (notmuch anyway just assumes that duplicates with the same Message-ID will never happen, which in my opinion is a bit optimistic, but I guess this design point is not going to change anyway and so am not going to argue further), but it is a problem with folder-based applications. When using a folder-based application, I don't want a Duplicates folder always popping up in my folder list with new messages until I read them, I want a Duplicates folder only to debug when things go weird and messages appear missing. > For the specific case of the duplicates folder: [...] Yes, now that I'm aware of this issue I can adapt my setup, likely by not indexing the duplicates folder indeed. However, I still think this is a big footgun, and take my missing 9 emails in the first 2 weeks of notmuch as proof of it. Just to repeat it at the end so my objective is clear: What I am wishing for is that when some tool outside of notmuch marked one of the message files as read and not the other, upon `synchronize_flags` notmuch takes the safe route of marking the overall message as unread in its database. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Mail to self
(sorry for sending twice, had the wrong From: line once again, hopefully I have fixed my client by adding this address to `user.other_email` now) Hi Gregor, Gregor Zattler writes: > For me, when I filtered emails in several folders and read them > with mutt (1) it was the other way around: I wished for the > possibility to mark them as read in all folders if read in one. This isn't incompatible, and I'm not wishing that notmuch stop marking as read per-message. However, I *am* wishing that when some other tool marked one of the message files as read and not the other, notmuch takes the safe route of marking the overall message as unread in its database. > But why would you tag a message (as opposed to a file) as > "unread" because it's a duplicate? Because usual folder-based applications display an unread marker with the number of unread messages near the folder, and this is a useless visual disturbance for the people for whom I administer the mail server. > If it's somehow important to you to know that a certain email > your read via notmuch is a duplicate, why not tag it as > "duplicate" instead? This is not a problem in notmuch (notmuch anyway just assumes that duplicates with the same Message-ID will never happen, which in my opinion is a bit optimistic, but I guess this design point is not going to change anyway and so am not going to argue further), but it is a problem with folder-based applications. When using a folder-based application, I don't want a Duplicates folder always popping up in my folder list with new messages until I read them, I want a Duplicates folder only to debug when things go weird and messages appear missing. > For the specific case of the duplicates folder: [...] Yes, now that I'm aware of this issue I can adapt my setup, likely by not indexing the duplicates folder indeed. However, I still think this is a big footgun, and take my missing 9 emails in the first 2 weeks of notmuch as proof of it. Just to repeat it at the end so my objective is clear: What I am wishing for is that when some tool outside of notmuch marked one of the message files as read and not the other, upon `synchronize_flags` notmuch takes the safe route of marking the overall message as unread in its database. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Mail to self
Hi Gregor, Gregor Zattler writes: > For me, when I filtered emails in several folders and read them > with mutt (1) it was the other way around: I wished for the > possibility to mark them as read in all folders if read in one. This isn't incompatible, and I'm not wishing that notmuch stop marking as read per-message. However, I *am* wishing that when some other tool marked one of the message files as read and not the other, notmuch takes the safe route of marking the overall message as unread in its database. > But why would you tag a message (as opposed to a file) as > "unread" because it's a duplicate? Because usual folder-based applications display an unread marker with the number of unread messages near the folder, and this is a useless visual disturbance for the people for whom I administer the mail server. > If it's somehow important to you to know that a certain email > your read via notmuch is a duplicate, why not tag it as > "duplicate" instead? This is not a problem in notmuch (notmuch anyway just assumes that duplicates with the same Message-ID will never happen, which in my opinion is a bit optimistic, but I guess this design point is not going to change anyway and so am not going to argue further), but it is a problem with folder-based applications. When using a folder-based application, I don't want a Duplicates folder always popping up in my folder list with new messages until I read them, I want a Duplicates folder only to debug when things go weird and messages appear missing. > For the specific case of the duplicates folder: [...] Yes, now that I'm aware of this issue I can adapt my setup, likely by not indexing the duplicates folder indeed. However, I still think this is a big footgun, and take my missing 9 emails in the first 2 weeks of notmuch as proof of it. Just to repeat it at the end so my objective is clear: What I am wishing for is that when some tool outside of notmuch marked one of the message files as read and not the other, upon `synchronize_flags` notmuch takes the safe route of marking the overall message as unread in its database. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Mail to self
> After a discussion on IRC, my understanding is the following. The > underlying behaviour that Leo is objecting to is that if any one file > with a given message-id has the ,S maildir flag, then when notmuch syncs > maildir flags to tags, it will remove the unread tag from that > message-id. After some back and forth and thinking about it, I think > notmuch's current behaviour is actually correct (given the constraint > that tags attach to message-ids). You could argue for different ways of > resolving conflicts for maildir flags in general, but the ",S" or "seen" > flag has fairly natural common sense semantics. I can confirm this is my issue. My thinking is that if any file does not have the ,S maildir flag, then I would prefer the mail to be marked as unread, as a read mail that is spuriously marked as unread is a small inconvenience, while an unread mail that is spuriously marked as read can have huge consequences. Actually, I just noticed while writing this mail that I had setup a sieve filter for duplicate email that put them in a “Duplicate” folder and automatically marks them as “read”, so that at the same time they wouldn't bother me in the thunderbird interface but I could still check dovecot's duplicate detection didn't have false positives. This behaviour of notmuch thus made me miss 9 emails in the 2 weeks I've been using it, the oldest being 12 days ago, without any warning. Well, now I know about it and can try to change my setup (except I can't really touch this sieve filter as other people rely on it), but… If this is a willing choice, I'd be glad were it revisited :) ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Mail to self
Leo Gaspard writes: > Hello, > > I'm looking for a way to have notmuch consider, when it finds both an > unread and a read mail with the same Message-Id (eg. sending a mail to > self from a phone), that the mail is unread (because I'd rather have too > many mails unread than miss important mail, and it's also useful for > tests). > > Do you see any way of having notmuch do this? After a discussion on IRC, my understanding is the following. The underlying behaviour that Leo is objecting to is that if any one file with a given message-id has the ,S maildir flag, then when notmuch syncs maildir flags to tags, it will remove the unread tag from that message-id. After some back and forth and thinking about it, I think notmuch's current behaviour is actually correct (given the constraint that tags attach to message-ids). You could argue for different ways of resolving conflicts for maildir flags in general, but the ",S" or "seen" flag has fairly natural common sense semantics. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
