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