From: Tomi Ollila <tomi.ollila@iki.fi>
To: Austin Clements <amdragon@MIT.EDU>
Subject: Re: [PATCH] lib: Save filenames for files detected as "not an email
	file" in the database.
In-Reply-To: <20120121181307.GI16740@mit.edu>
References: <1327096827-5760-1-git-send-email-amdragon@mit.edu>
	<m2k44lfksv.fsf@guru.guru-group.fi>
	<20120121181307.GI16740@mit.edu>
User-Agent: Notmuch/0.11+71~gefa5d6c (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Sat, 21 Jan 2012 22:23:59 +0200
Message-ID: <m2hazo6bz4.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list

On Sat, 21 Jan 2012 13:13:07 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> Quoth Tomi Ollila on Jan 21 at 11:48 am:
> > On Fri, 20 Jan 2012 17:00:27 -0500, Austin Clements <amdragon@MIT.EDU> wrot> > 
> > > -large so the detection could be potentially slow). 2. A "notmuch
> > > -search" syntax could be added to allow the user to find these files,
> > > -(and perhaps delete them or move them away as appropriate).
> > > +Add a "notmuch search" syntax to allow uses to find files recorded as
> > > +non-emails in the database (and perhaps delete them or move them away
> > > +as appropriate).
> > 
> > Could these messages be tagged with some fixed tag -- we already have
> > 'signed' and 'attachment' tag. maybe 'nonemail' (or something) could
> > be used for these messages ?
> 
> They aren't actually messages.  Messages have a lot of basic metadata
> that non-email files don't have, so I went with distinct types of
> documents, figuring that would be much less disruptive than having to
> deal with message objects that don't support most message methods.
> For example, if there were a tag (or any general way to query this),
> it's unclear what the output of
>  notmuch search --output=summary tag:nonemail
> would be.

yes, I started to think all these issues *after* sending that email.
bunch on extra if's to the code and so on; better think something
else...

> This isn't necessarily the right approach, but if non-emails *are*
> represented as messages, I'm not sure what to do with things like
> notmuch_message_get_message_id and notmuch_message_get_thread_id or
> how to maintain backwards compatibility for callers that don't expect
> queries to return non-emails.

so true.

Tomi