On Thu, 03 Dec 2009 14:33:51 +0100, Gregor Hoffleit <gregor@hoffleit.de> wrote:
> 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. 

Hi Gregor, welcome to notmuch!

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

Hey, we like our rough edges *really* rough, dontcha know?

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

Hey, that sounds really interesting! I'll definitely look forward to
what you come up with.

> 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?).

I'd love to see one. The quick scan I did for human-readable time
formatting found stuff in languages like perl, python, and ruby, but I
didn't notice much in C. I also didn't look close enough to see if any
of these have multi-language suport.

> 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.

Good point. There's actually a weird mix of raw and cooked output from
the notmuch command line right now. As you noticed, "notmuch search"
cooks the date too much, (and in a way useful only to English speakers).

Meanwhile, the "notmuch show" output is far too raw to be read without a
client prettying it up. (The message{ header{ body{ body} header}
message} stuff is almost as bad as XML.)

> Any comment? Any other thoughts about this?

I think I'd like to see notmuch output get both more cooked and more raw
at the same time. I'd like things to be more cooked by default,
("notmuch show" shouldn't print the ugly delimiters, should indent
messages, and should start up a pager). And then we just need options
that frontends can pass to get the raw output, (but quoted
safely---which the current "notmuch show" output is *not*).

-Carl

PS. If you're worried about multi-lingualization issues for notmuch,
you'll want to know that notmuch is (for now) unconditionally
instructing Xapian to use an English-language stemmer when indexing
mail. Obviously we'll want to support a configuration option for
specifying a default stemmer, (Xapian has stemmers for many languages I
believe). And a step beyond that would support different languages for
different emails, but that sounds like something "hard" to identify.