Quoth Mark Walters on Oct 24 at 10:23 am: > > Hi > > I definitely like the idea: some comments below. Agreed. > On Fri, 24 Oct 2014, David Edmondson <dme@dme.org> wrote: > > In addition to the :authors attribute of each search result, include > > :authors_matched and :authors_non_matched attributes. Both attributes > > are always included. If there are no non-matching authors, the > > :authors_non_matched attribute is set to the empty string. > > What about having both authors_matched and authors_not_matched as lists > of authors (ie one string for each author)? Then emacs, for example, > wouldn't try and parse the string back into authors before > splitting. And authors_non_matched could be an empty list when > appropriate which seems more natural than the empty string. > > All the above is based on what a client might want in the output rather > than what is easy or sensible to implement in the C code. I was going to suggest exactly the same thing. And I think there's a fairly easy way to do it in C code that will also prevent library interface bloat: instead of introducing new library APIs to get at this information, just use the existing notmuch_thread_get_messages API and construct the matched and non-matched lists in the CLI. Doing it in the CLI wouldn't require the library to export yet another string list structure, which is always a huge pain (thanks C!), and wouldn't introduce more "helper" functions into the library API. I think the only disadvantage to doing this would be some duplication of the {matched_,}authors_{array,hash} logic into the CLI, but those are only there to support notmuch_thread_get_authors, which I think is a huge hack and should go away in the long term. (And, by doing this list building in the CLI, we avoid further embellishing the unnecessary "get thread authors" API).