ordering threads by the latest message in a thread ?

2011-02-09 Thread Sebastien Binet
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

2011-02-09 Thread Jesse Rosenthal
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


ordering threads by the latest message in a thread ?

2011-02-09 Thread Jesse Rosenthal

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 ?

2011-02-09 Thread Daniel Kahn Gillmor
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 ?

2011-02-09 Thread Sebastien Binet

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 ?

2011-02-09 Thread Jameson Rollins
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 ?

2011-02-09 Thread Sebastien Binet

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 ?

2011-02-09 Thread Daniel Kahn Gillmor
On 02/09/2011 01:02 PM, Jameson Rollins wrote:
 On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet bi...@cern.ch 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 ?

2011-02-09 Thread Sebastien Binet
On Wed, 9 Feb 2011 13:36:17 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
 
 On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor 
 d...@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


pgpfwSXtAcTaE.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Remote usage script updated

2011-02-09 Thread Jesse Rosenthal
Michal,

On Sun, 06 Feb 2011 00:58:29 +0100, Michal Sojka sojk...@fel.cvut.cz 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