ordering threads by the latest message in a thread ?
hi there, right now, it seems like the messages are displayed and ordered in my inbox according to the date of the *first* message in a thread. that doesn't sound right to me as one can easily miss new replies to that thread (at least I did.) is there a way to modify this in the notmuch emacs interface so that threads are ordered according to the *latest* message in a thread instead ? (I am not fluent in lisp -- even if I am regularly trying to work on that specific issue -- so I might have missed an obvious way to perform such a thing.) -- @+ -s pgpJbaRfII32Q.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: ordering threads by the latest message in a thread ?
On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet wrote: > right now, it seems like the messages are displayed and ordered in my > inbox according to the date of the *first* message in a thread. > > that doesn't sound right to me as one can easily miss new replies to > that thread (at least I did.) > > is there a way to modify this in the notmuch emacs interface so that > threads are ordered according to the *latest* message in a thread > instead ? Hi, Sebastien. You can access the notmuch emacs config parameters by doing: M-x customize-group notmuch There is a variable there called "Notmuch Search Oldest First" that does what you're looking for. jamie. pgpvrWzq4JqM4.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: ordering threads by the latest message in a thread ?
On 02/09/2011 01:02 PM, Jameson Rollins wrote: > On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet wrote: >> is there a way to modify this in the notmuch emacs interface so that >> threads are ordered according to the *latest* message in a thread >> instead ? [...] > There is a variable there called "Notmuch Search Oldest First" that does > what you're looking for. Jameson, are you saying that "Search Oldest First" not only inverts the order of the threads, but also changes the a date a given thread is associated with? I guess that's a reasonable thing to do, but it's certainly not clear from the "customize-group" page that the variable affects both of these behaviors. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: ordering threads by the latest message in a thread ?
On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor wrote: > > Jameson, are you saying that "Search Oldest First" not only inverts the > order of the threads, but also changes the a date a given thread is > associated with? The procedure is to match threads by either the oldest matching message (in oldest first) or newest matching message (in newest first). So matching newest first will make the thread with new messages go to the top. But in oldest first -- which is what I imagine Sebastian was looking at in the inbox -- the thread with an older inbox message will appear further up. So if Sebastian's message is tagged "inbox" this thread will appear, under oldest-first, when he sent it; if it's not but Jamie's is, then it will appear under Jamie's. But it'll appear under mine regardless in newest first. I don't believe emacs has anything to do with it -- it's how the nm binary orders threads as output to "search." Apologies if this is restating what everyone already knew -- I couldn't quite tell. Best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: ordering threads by the latest message in a thread ?
On Wed, 9 Feb 2011 13:36:17 -0500, Jesse Rosenthal wrote: > > On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor > wrote: > > > > Jameson, are you saying that "Search Oldest First" not only inverts the > > order of the threads, but also changes the a date a given thread is > > associated with? > > The procedure is to match threads by either the oldest matching message > (in oldest first) or newest matching message (in newest first). So > matching newest first will make the thread with new messages go to the > top. But in oldest first -- which is what I imagine Sebastian was > looking at in the inbox -- the thread with an older inbox message will > appear further up. > > So if Sebastian's message is tagged "inbox" this thread will appear, > under oldest-first, when he sent it; if it's not but Jamie's is, then it > will appear under Jamie's. But it'll appear under mine regardless in > newest first. I don't believe emacs has anything to do with it -- it's > how the nm binary orders threads as output to "search." aha! I knew about the 'o' toggle that one could play with to display the threads, but I didn't notice this also modified how their ordering worked out: I naively thought it was just a matter of reverting the list. so, say I have the following messages and threads: id_0 1/3 [important meeting] - (received Monday) id_1 2/3 [important meeting] - (received Tuesday) id_2 1/1 [pick groceries] - (received Wednesday) id_3 3/3 [important meeting] - (received Thursday) id_4 1/1 [another title] - (received Friday morning) if I have 'Search Oldest first' "on", I'd get the following id_0 [and id_1 and id_3 folded in] id_2 id_4 and if it is "off": id_4 id_0 [and id_1 and id_3 folded in] id_2 but what I'd like to have is instead: id_2 id_0 [and id_1 and id_3 folded in] id_4 id_0 and friends come after id_2 because id_3 is more recent than id_2 but older than id_4 so: oldest first but only the latest of the messages of a thread to be considered for the thread-to-thread ordering. I prefer to process my emails like a stack growing from top to bottom ;) -s pgpfwSXtAcTaE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Remote usage script updated
Michal, On Sun, 06 Feb 2011 00:58:29 +0100, Michal Sojka wrote: > Hmm, this code worked well with dropbear ssh server but it seems that > with openssh server the result is not that good. Namely, if the master > connection is dead, the command running true blocked for a long time. Seemed to work okay for me when I played around with it a bit (in different circumstances, and with a confused laptop waking up from hibernation). But I'll hold off on updating it till I can figure out the most reliable way. I'll definitely take your suggestion to use printf instead of manually escaping characters. Thanks, in any event, for your suggestions! By the way, I've also realized that most attachment downloading is done not by "--format=raw" but by "notmuch part". It's possible to do caching there as well. There are a few options there: * One option would be to just cache by the attachment number -- but this is very fragile if you delete an attachment through mutt or some other client that allows it. * cache by the hash of the attachment. The idea is that asking the server to fetch it, hash it, and send the hash would still save time over sending the whole attachment. Probably -- though most attachments are small enough and most connections are fast enough that this might not actually matter. * Actually stick the attachment hash in the json output in the first place. But this would be a lot of trouble for a small gain for very few. It would come in handy when I'm trying to get a biggish pdf over a bus's slow wireless connection. But it's certainly not a priority. Best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ordering threads by the latest message in a thread ?
hi there, right now, it seems like the messages are displayed and ordered in my inbox according to the date of the *first* message in a thread. that doesn't sound right to me as one can easily miss new replies to that thread (at least I did.) is there a way to modify this in the notmuch emacs interface so that threads are ordered according to the *latest* message in a thread instead ? (I am not fluent in lisp -- even if I am regularly trying to work on that specific issue -- so I might have missed an obvious way to perform such a thing.) -- @+ -s -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110209/5ce888fb/attachment.pgp>
ordering threads by the latest message in a thread ?
On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet wrote: > right now, it seems like the messages are displayed and ordered in my > inbox according to the date of the *first* message in a thread. > > that doesn't sound right to me as one can easily miss new replies to > that thread (at least I did.) > > is there a way to modify this in the notmuch emacs interface so that > threads are ordered according to the *latest* message in a thread > instead ? Hi, Sebastien. You can access the notmuch emacs config parameters by doing: M-x customize-group notmuch There is a variable there called "Notmuch Search Oldest First" that does what you're looking for. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110209/afd8ba3b/attachment.pgp>
ordering threads by the latest message in a thread ?
On 02/09/2011 01:02 PM, Jameson Rollins wrote: > On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet wrote: >> is there a way to modify this in the notmuch emacs interface so that >> threads are ordered according to the *latest* message in a thread >> instead ? [...] > There is a variable there called "Notmuch Search Oldest First" that does > what you're looking for. Jameson, are you saying that "Search Oldest First" not only inverts the order of the threads, but also changes the a date a given thread is associated with? I guess that's a reasonable thing to do, but it's certainly not clear from the "customize-group" page that the variable affects both of these behaviors. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110209/24972cf0/attachment.pgp>
ordering threads by the latest message in a thread ?
On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor wrote: > > Jameson, are you saying that "Search Oldest First" not only inverts the > order of the threads, but also changes the a date a given thread is > associated with? The procedure is to match threads by either the oldest matching message (in oldest first) or newest matching message (in newest first). So matching newest first will make the thread with new messages go to the top. But in oldest first -- which is what I imagine Sebastian was looking at in the inbox -- the thread with an older inbox message will appear further up. So if Sebastian's message is tagged "inbox" this thread will appear, under oldest-first, when he sent it; if it's not but Jamie's is, then it will appear under Jamie's. But it'll appear under mine regardless in newest first. I don't believe emacs has anything to do with it -- it's how the nm binary orders threads as output to "search." Apologies if this is restating what everyone already knew -- I couldn't quite tell. Best, Jesse
ordering threads by the latest message in a thread ?
On Wed, 9 Feb 2011 13:36:17 -0500, Jesse Rosenthal wrote: > > On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor fifthhorseman.net> wrote: > > > > Jameson, are you saying that "Search Oldest First" not only inverts the > > order of the threads, but also changes the a date a given thread is > > associated with? > > The procedure is to match threads by either the oldest matching message > (in oldest first) or newest matching message (in newest first). So > matching newest first will make the thread with new messages go to the > top. But in oldest first -- which is what I imagine Sebastian was > looking at in the inbox -- the thread with an older inbox message will > appear further up. > > So if Sebastian's message is tagged "inbox" this thread will appear, > under oldest-first, when he sent it; if it's not but Jamie's is, then it > will appear under Jamie's. But it'll appear under mine regardless in > newest first. I don't believe emacs has anything to do with it -- it's > how the nm binary orders threads as output to "search." aha! I knew about the 'o' toggle that one could play with to display the threads, but I didn't notice this also modified how their ordering worked out: I naively thought it was just a matter of reverting the list. so, say I have the following messages and threads: id_0 1/3 [important meeting] - (received Monday) id_1 2/3 [important meeting] - (received Tuesday) id_2 1/1 [pick groceries] - (received Wednesday) id_3 3/3 [important meeting] - (received Thursday) id_4 1/1 [another title] - (received Friday morning) if I have 'Search Oldest first' "on", I'd get the following id_0 [and id_1 and id_3 folded in] id_2 id_4 and if it is "off": id_4 id_0 [and id_1 and id_3 folded in] id_2 but what I'd like to have is instead: id_2 id_0 [and id_1 and id_3 folded in] id_4 id_0 and friends come after id_2 because id_3 is more recent than id_2 but older than id_4 so: oldest first but only the latest of the messages of a thread to be considered for the thread-to-thread ordering. I prefer to process my emails like a stack growing from top to bottom ;) -s -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110209/06be9647/attachment.pgp>
Remote usage script updated
Michal, On Sun, 06 Feb 2011 00:58:29 +0100, Michal Sojka wrote: > Hmm, this code worked well with dropbear ssh server but it seems that > with openssh server the result is not that good. Namely, if the master > connection is dead, the command running true blocked for a long time. Seemed to work okay for me when I played around with it a bit (in different circumstances, and with a confused laptop waking up from hibernation). But I'll hold off on updating it till I can figure out the most reliable way. I'll definitely take your suggestion to use printf instead of manually escaping characters. Thanks, in any event, for your suggestions! By the way, I've also realized that most attachment downloading is done not by "--format=raw" but by "notmuch part". It's possible to do caching there as well. There are a few options there: * One option would be to just cache by the attachment number -- but this is very fragile if you delete an attachment through mutt or some other client that allows it. * cache by the hash of the attachment. The idea is that asking the server to fetch it, hash it, and send the hash would still save time over sending the whole attachment. Probably -- though most attachments are small enough and most connections are fast enough that this might not actually matter. * Actually stick the attachment hash in the json output in the first place. But this would be a lot of trouble for a small gain for very few. It would come in handy when I'm trying to get a biggish pdf over a bus's slow wireless connection. But it's certainly not a priority. Best, Jesse