Re: [PATCH v3 0/2] notmuch hooks

[Austin Clements <amdragon@MIT.EDU>]

Quoth Jani Nikula on Dec 07 at  8:05 pm:
> On Tue, 06 Dec 2011 22:16:37 -0500, Tom Prince <tom.prince@ualberta.net> wrote:
> > On Tue, 06 Dec 2011 18:47:01 -0800, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> > > Also, what if we make it so that the post-new hook script only runs if
> > > notmuch new processes new messages?  All of my post-new functions don't
> > > need to be run at all if there is no new mail.
> 
> I think the post-new hook should be run always (provided there have been
> no errors). I think it might be surprising not to, and some users might
> use the hook for something other than tagging.
> 
> > Or would it make sense to pass this information to the hook somehow?
> 
> It would, but as I wrote in id:"87mxb8kt5r.fsf@nikula.org", I think that
> should come as another patch afterwards. I know I can't decide yet what
> should be passed and how. Processed message counts (added, deleted,
> renamed) could be passed on the command line, but how useful is that
> really? The same can be easily achieved through initial tagging.

I would worry about creating any hook interface that's difficult to
use correctly.  For example, notmuch new could be interrupted right
between processing all new messages and calling the hook; then, on the
next run, it'll tell the hook that nothing happened.  More generally,
any message counts passed to a hook can't be better than lower bounds
and I don't see how you could use such information correctly in a
hook.

Using an initial "new" tag that you remove at the end of a hook,
though, is stable.  It guarantees that the hook is aware of any new
messages at least once.  If a hook needs a new message count, it
should run notmuch count tag:new.

> Message-ids could not be passed on the command line (there just can be
> too many of them) so it would require setting up a pipe and feeding them
> to stdin of the hook. The post-new hook should be run after the database
> has been closed, but the message-ids are not saved during notmuch new
> processing. Saving them for later gets complicated for not much extra
> benefit in addition to creative use of initial tagging, as far as I can
> see. Plus interrupting the post-new hook with this setup would screw up
> your processing if it only depended on the message-ids.

I think this would have to be a separate hook that runs concurrently
with new, both so that new doesn't have to buffer this information and
so that the majority of post-new hooks that don't need this
information don't have to deal with it.  Though, as with passing
message counts to post-new, I worry about actually do anything
correctly in such a hook in the presence of interruptions and
failures.

> All in all, I'd postpone all of this until later.

That sounds wise.