From: Tomi Ollila <tomi.ollila@iki.fi>
To: Jani Nikula <jani@nikula.org>, Austin Clements <amdragon@MIT.EDU>,
	Aaron Ecay <aaronecay@gmail.com>
Subject: Re: [PATCH] emacs: call "notmuch tag" only once when archiving a
	thread
In-Reply-To: <87k451clp0.fsf@nikula.org>
References: <1325615346-8302-1-git-send-email-jani@nikula.org>
	<m2hb09kj0m.fsf@gmail.com> <87fwftao1b.fsf@nikula.org>
	<m262glk82m.fsf@gmail.com> <20120109011259.GD20796@mit.edu>
	<87k451clp0.fsf@nikula.org>
User-Agent: Notmuch/0.10.2+157~g442d405 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 09 Jan 2012 12:38:58 +0200
Message-ID: <yf6sjjp9n3x.fsf@taco2.nixu.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

On Mon, 09 Jan 2012 08:41:15 +0000, Jani Nikula <jani@nikula.org> wrote:
> On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements <amdragon@MIT.EDU> wro=
te:
> > Quoth Aaron Ecay on Jan 08 at  7:56 pm:
> > > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula <jani@nikula.org> wro=
te:
> > >=20
> > > [...]
> > >=20
> > > > In the show view it only modifies the messages that are currently
> > > > visible. This is to make sure you don't accidentally archive things=
 that
> > > > have arrived after refreshing the buffer. I think this is safest.
> > >=20
> > > Hmm.  Perhaps it would make sense to add a check in the search view t=
hat
> > > the thread being archived[1] has the same number of messages as it did
> > > when the buffer was constructed.  (The information on how many messag=
es
> > > the thread has is in the buffer; we would then compare this to the re=
sult
> > > of =E2=80=9Cnotmuch count thread:000foo=E2=80=9D when the user reques=
ts to archive.)  If
> > > the counts don=E2=80=99t match, the interface should show a message i=
n the echo
> > > area and (probably) refuse to do the tagging.
> >=20
> > That sounds like a clever workaround.
>=20
> The downside is that there's still a race condition: you could get new
> messages between checking the number of messages in the thread and
> tagging. The window for error would be much smaller than now, but it's
> still there. (You could check afterwards if this happened, and notify
> the user, "oooops, I just tagged N messages more than you intended"...)

And this could also be "false alarm" if the the new messages arrived
after tagging but before checking...

>=20
> J.

Tomi