unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: David Bremner <david@tethera.net>
To: Sean Whitton <spwhitton@spwhitton.name>, notmuch@notmuchmail.org
Subject: Re: Forcing a sync of maildir flags?
Date: Tue, 03 May 2022 09:14:59 -0300	[thread overview]
Message-ID: <87zgjy4xto.fsf@tethera.net> (raw)
In-Reply-To: <87wnf334d9.fsf@melete.silentflame.com>

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello David,
>> # next line is a no-op, because it already doesn't have the unread tag
>> notmuch tag -unread folder:sent
>
> Seems also worth noting that to my mind it ultimately shouldn't be
> necessary to run that command -- notmuch should notice that one copy of
> the message has different maildir flags to the other in a way that's out
> of sync with the notmuch tags it has.
>

Right, that's probably a useful way to think about the problem.

>> The key point is that from notmuch's point of view the message never has
>> the unread tag, so there is no change for "notmuch tag" to sync with
>> maildir flags.
>>
>> It doesn't seem to make a difference if I put the copy in inbox/new or
>> inbox/cur, so I don't think it is related to the previous efforts not to
>> prematurely move files out of new/.
>>
>> As far as I can tell, notmuch-new (unlike notmuch-insert) does not call
>> notmuch_message_tags_to_maildir_flags, so the maildir flags on the newly
>> discovered copy are not updated. Perhaps it should, but that seems like
>> a pretty big change, so I want to proceed with caution.
>
> It makes sense to me for notmuch-new to call that function too, fwiw.

I have the same intuition. Unfortunately it is not as simple as adding
in a couple calls to this function. The complications I am aware of so
far are

1) We need to distinguish between when a newly discovered file should
update tags, and when the newly discovered file should have it's flags
updated.

2) Renaming files in the middle of notmuch new needs to be done
carefully in order that notmuch doesn't lose track of the files. They
are only lost until the next run of notmuch-new, but it's not ideal.

d


  reply	other threads:[~2022-05-03 12:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20  4:58 Forcing a sync of maildir flags? Sean Whitton
2020-02-20 12:22 ` David Bremner
2020-02-20 13:21   ` David Bremner
2020-02-20 21:19   ` Sean Whitton
2020-02-21  0:06     ` David Bremner
2020-02-21 19:54       ` Sean Whitton
2022-05-01 23:23         ` David Bremner
2022-05-02 23:24           ` Sean Whitton
2022-05-03 12:14             ` David Bremner [this message]
2022-05-03 23:59               ` Sean Whitton
2022-03-22 19:44   ` Sean Whitton
2022-04-05  4:48     ` Sean Whitton
2022-04-13 10:27       ` Gregor Zattler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgjy4xto.fsf@tethera.net \
    --to=david@tethera.net \
    --cc=notmuch@notmuchmail.org \
    --cc=spwhitton@spwhitton.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).