Re: web interface to notmuch

[Matthew Lear <matt@bubblegen.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

I've had a play with this this morning. It's great! The speed and page
loading efficiency is fantastic. Would be really nice if we could go
next/previous in the thread (yes I know I'm complaining about one extra
mouse click). Also, if I select a date via the drop down I need to delete
the timestamp that appears prior to searching, otherwise there is a xapian
error.
This is definitely a candidate solution for me, though.
Thanks Brian!
Cheers,
  Matt

On Fri, 27 Oct 2017, 05:24 Daniel Kahn Gillmor, <dkg@fifthhorseman.net>
wrote:

> On Fri 2017-10-27 00:04:21 -0400, Brian Sniffen wrote:
> > Thanks!  The part I'm happiest about is the speed:
>
> amen, it feels very lightweight.
>
> > Very careful examination would have shown that the em-dashes between
> > author and subject were red for matches.  Now matches are in italics.
>
> cool.  perhaps assigning a class to those elements and stashing some CSS
> would make that easier for folks to experiment with (and probably reduce
> the bytecount transfered)?
>
> or would that hurt the rendering time for some reason i'm unaware of?  i
> haven't thought about these mechanics as much as you have.
>
> > Yup.  The thread object isn't accessible by then: it existed in the
> > scope of the search query, and is gone by the time we show the message.
> > get_replies isn't available.  So what's the alternative?
> > get_thread_id(), search for that thread id, identify this message *in*
> > that thread id, and then link to the next message with a "next" link?
> > While doing it, why not show the thread structure at the bottom of the
> > message, I guess.
>
> yep, i think that's right.
>
> > With bleach integrated (all of five lines), I think this is safe enough
> > to let random notmuch users run it.  The worst they'll do is expose
> > their mailstore on tcp/8080.  Any interest in taking this into the
> > upstream contrib directory?
>
> Yes, i think this should move into contrib/ upstream.  And we should
> think about what might be the appropriate way to package it for debian,
> too.
>
>         --dkg
>

[-- Attachment #2: Type: text/html, Size: 2550 bytes --]