BUG: unexpected prompt for Recipients during Fcc

2020-03-06 Thread Antoine Beaupré
I'm having trouble writing long encrypted emails. On startup, this works: 1. start emacs 2. start notmuch (M-x notmuch-hello) 3. compose email ("c"), encrypted ("control-enter e") 4. send ("control-c c") But eventually, I get into this weird state. I originally thought it was related with

Re: oldest-first

2020-03-06 Thread Ryan Tate
> On Mar 6, 2020, at 11:50 AM, Ryan Tate wrote: > The documentation seems to be in error, No, I didn’t think about it hard enough, sorry. (Reversing threads sorted by newest message vs sorting from scratch by oldest message.) > ___ notmuch

Re: oldest-first

2020-03-06 Thread Ryan Tate
> On Mar 6, 2020, at 10:47 AM, David Bremner wrote: > > There is the following documentation in notmuch-search(1). > > Note: The thread order will be distinct between these two options (beyond > being sim‐ > ply reversed). When sorting by oldest-first the threads will be sorted by >

Re: oldest-first

2020-03-06 Thread Tom Hirschowitz
Thanks for your answer. This is indeed not a bug then. It's not important, but my preferred sort order would be the opposite of newest-first. I prefer seeing older threads first, but often find myself missing recent messages in threads because they have older unread messages hence are

Re: oldest-first

2020-03-06 Thread David Bremner
Tom Hirschowitz writes: > Hi all, > > The order returned by notmuch with the oldest-first option looks wrong > to me: as far as I can see, threads are sorted according to their oldest > unread message, but in any case, it is not the converse of the > newest-first ordering. > > Is this a bug? And

oldest-first

2020-03-06 Thread Tom Hirschowitz
Hi all, The order returned by notmuch with the oldest-first option looks wrong to me: as far as I can see, threads are sorted according to their oldest unread message, but in any case, it is not the converse of the newest-first ordering. Is this a bug? And if not, how hard would it be to add