From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Carl Worth <cworth@cworth.org>
Subject: Re: [PATCH 1/2] Add 'cat' subcommand
In-Reply-To: <871ve8wc30.fsf@yoom.home.cworth.org>
References: <1271747793-17507-1-git-send-email-sojkam1@fel.cvut.cz>
	<87pr1u7fnu.fsf@ut.hh.sledj.net> <87fx2qmtok.fsf@SSpaeth.de>
	<4BCD7EA0.3080505@fel.cvut.cz>
	<871ve8wc30.fsf@yoom.home.cworth.org>
Date: Thu, 22 Apr 2010 08:38:54 +0200
Message-ID: <871ve8ng8x.fsf@steelpick.2x.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list

On Thu, 22 Apr 2010, Carl Worth wrote:
> On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> > On 20.4.2010 09:21, David Edmondson wrote:
> >  > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> >  > rather than a message id (id:foo@bar.com)?
> > 
> > The reason is that I want be able to distinguish between several 
> > messages with the same id.
> 
> All other commands currently accept the generic search terms to specify
> messages, (even a command like "notmuch reply" for which it would have
> been natural to accept only a single message).
> 
> So I'd prefer to have this command behave just like all others and use
> the same naming.
> 
> The question of how to unambiguously refer to a single file is
> orthogonal, (and similarly applies to all commands, such as "notmuch
> tag" etc.). I would recommend supporting a search syntax something like:
> 
> 	filename:/complete/path/to/file
> 
> for that use case. And this should work fine whether the filenames are
> actual filenames or keys into some abstract file store of some sort.
> 
> What do you think?

It sounds reasonable. I looked at the code to see how this could be
implemented and I have a few questions:

If a filename:dir/file term is present in the query, it will be
necessary to first query the database for directory:dir to find the
<directory_ID> and then put in the query
file-direntry:<directory_ID>:file. This conversion is already
implemented in _notmuch_database_filename_to_direntry(). Right?

_notmuch_database_filename_to_direntry() requires writable database as
it creates the directory document if it doesn't exist. This is probably
not what we want for filename: queries - if the user types the filename
incorrectly, the nonexisting directory document could be added to the
database. So I think that _notmuch_database_find_directory_id() should
be modified to not modify the database. The directory documents should
be created somewhere else in notmuch new path. Do you agree?

-Michal