From: Austin Clements <amdragon@MIT.EDU>
To: Jesse Rosenthal <jrosenthal@jhu.edu>
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: Replacing my name/email with "me" (or similar) in author lists
Date: Wed, 29 Feb 2012 17:47:46 -0500 [thread overview]
Message-ID: <87k435ntnx.fsf@awakening.csail.mit.edu> (raw)
In-Reply-To: <877gz5tz8p.fsf@jhu.edu>
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.
next prev parent reply other threads:[~2012-02-29 22:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-25 16:34 Replacing my name/email with "me" (or similar) in author lists Daniel
2012-02-26 11:22 ` Patrick Totzke
2012-02-26 16:41 ` Daniel Schoepe
2012-02-26 16:51 ` David Bremner
2012-02-26 21:59 ` Tom Prince
2012-02-29 15:05 ` Jesse Rosenthal
2012-02-29 15:36 ` Austin Clements
2012-02-29 15:50 ` Jesse Rosenthal
2012-02-29 22:47 ` Austin Clements [this message]
2012-03-01 14:28 ` Jesse Rosenthal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k435ntnx.fsf@awakening.csail.mit.edu \
--to=amdragon@mit.edu \
--cc=jrosenthal@jhu.edu \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).