Hi there,

first a short introduction: I was a mutt user for ages. When I read
about Sup, I was intrigued. After a short evaluation period, I switched
to Sup, which I'm now using since six months. 

Sup has many rough edges on its own, and it's not that easy to fix some
of them from the current codebase. notmuch looks like a clean restart of
the same idea, but with a different architecture. I like the concept of
a command line tool with a minimal set of functionality as a common
core, upon which different clients can build on.


But. Compared to Sup, the current notmuch clients suck :-)


Today: Sup's search-results-mode. It has a lot of polish that's plainly
missing from notmuch.el (or notmuch.vim):

- Sup's display is much terse than notmuch, still
- Sup manages to display the first few words of the first unread message
  in the thread.
- If a thread contains many authors, Sup shows only the firstnames.
  If that's still too long to fit, it cuts off at some point.
- User's name is rewritten as 'me'.
- The message date format needs only 8 characters (notmuch: 12).
- Message count is only displayed when necessary (>=1).
- Threads with unread messages are bold (resp. hilighted).
- Threads with attachments are marked with an "@".
- Threads with mails to user are marked with an ">".
- Different colors of tags, message content.

All in all, 'notmuch search' is a raw representation of field values,
while Sup's search-results-mode shows a polished and terse
interpretation of the same values, for human beings, even optimized for
the current display width.

Now notmuch.el and notmuch.vim just display the output of 'notmuch
search', verbatim (perhaps enhanced with coloring based on regexes).


I'm experimenting with a notmuch web client (currently 'evenless'),
trying to replicate much of the feeling of Sup, in a web client.

First, I took the output of 'notmuch search', parsed it and tried to
reformat it like Sup. That worked well for all fields but the date
field: In contrast to the other fields, notmuch's date representation
is intended for direct consumption by humans (english-speaking, that is
;-).


I noticed this entry in TODO:

    Add a "--format" option to "notmuch search", (something printf-like
    for selecting what gets printed).

Since I'm not eager to write a format parser, I started to implement
--format as an enumerating option notmuch_format_t. By now, I have
NOTMUCH_FORMAT_DEFAULT and NOTMUCH_FORMAT_SUP. do_search_threads() does
the real work. In notmuch-time.c, I have implemented an alternative nice
and terse time representation, notmuch_time_relative8_date().

I realized, though, that at this point I would have to hardcode things
like ANSI coloring into NOTMUCH_FORMAT_SUP.

Also, any l10n (e.g. of time representation) would have to be hardcoded
as well (btw, anybody knows a library for human readable time
representations which supports l10n and i18n?).


So perhaps it's better to move the polishing into the client (Yeah!
Python to the rescue! ;-). But then, 'notmuch search' would need to
return some raw representation of the date field as well.


Any comment? Any other thoughts about this?



Regards,
    Gregor Hoffleit