From: Austin Clements <amdragon@MIT.EDU>
To: Jesse Rosenthal <jrosenthal@jhu.edu>
Subject: Re: Replacing my name/email with "me" (or similar) in author lists
In-Reply-To: <877gz5tz8p.fsf@jhu.edu>
References: <slrnjki3c7.tcm.quite@kelebek.lublin.se>
	<20120226112210.5422.8471@brick.lan>
	<87ehthfsyn.fsf@schoepe.localhost> <87fwdxk062.fsf@zancas.localnet>
	<87ehth8dd2.fsf@hermes.hocat.ca> <878vjl3ck3.fsf@jhu.edu>
	<20120229153657.GA772@mit.edu> <877gz5tz8p.fsf@jhu.edu>
User-Agent: Notmuch/0.11.1+252~gdf1a6d5 (http://notmuchmail.org) Emacs/23.3.1
	(i486-pc-linux-gnu)
Date: Wed, 29 Feb 2012 17:47:46 -0500
Message-ID: <87k435ntnx.fsf@awakening.csail.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

On Wed, 29 Feb 2012 10:50:46 -0500, Jesse Rosenthal <jrosenthal@jhu.edu> wrote:
> On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> > What if the output of search (say, specifically the JSON format)
> > included information on each message in the thread such as the
> > 'message' production from devel/schemata minus the body field?  Then
> > the frontend would have loads of information it could produce its own
> > summaries from.  (Plus, with a little tweaking, I don't think this
> > would be any more expensive than producing the current notmuch search
> > summary output.)
> 
> I was hoping for something like that when I started fiddling. But it's
> still going to end up being a library question, because
> notmuch-search.c, is tied pretty tightly to the lib: i.e. it uses
> functions like `notmuch_thread_get_authors (thread)'. I was using the
> python bindings, and I ended up having to make a second query off the
> thread id (I could have recursed through the messages too, I suppose).
> 
> So I guess what I'm saying is that what you're suggesting sounds great,
> but we'd still have to either (a) add new library functions
> (`notmuch_thread_get_recipients', `notmuch_thread_abbrev_me'), (b) keep
> them all in the client and make pazz and scripters recreate them, or (c)
> play around in the sort of client-library space that it sounded like
> Bremner was suggesting.

I was suggesting just using notmuch_thread_get_toplevel_messages in
search (essentially, mixing a bit of show into search).  No library
changes necessary.

It may still be useful to have a collection of *utilities* that could be
reused in bindings; basically, things that currently live in the CLI but
could be broken out.  These should live outside of libnotmuch proper.
My concern would be what we put in such a library.  Currently, the CLI's
internal architecture is quite agile, but as soon as you put some of
that in a library, you have a library interface to support.