Re: New problem "next unread" (not sure how new)

[Peter Bloomfield <PeterBloomfield bellsouth net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Jack:

On 05/15/2017 05:46:42 PM Mon, Jack wrote:
> Hello all,
>
> I think I started noticing this relatively recently - probably about the time (or shortly after) the recent set of updates related to threading.  (git head)  Most of the time I hit the "Next unread" button (on the toolbar) when all messages in the current mailbox are read, it does go to an unread message in the next mailbox with any uread messages.  I actually still haven't paid enough attention to confirm how it chooses the specific message.  However, sometimes (fairly consistent by mailbox, I think, but all my mailboxes are maildir (except inbox)) it goes to the message with the id number one less than the first unread message.  As we've discussed in the past, the message id ordering seems to be essentially random, but likely the order in which the messages are read when scanning (or reading) the directory.  Is it possible there is an off-by-one thing going on?  I'd be more certain if it were more consistent.  The reason it's annoying is that due to the ordering - it sometimes 
>  chooses a message nowhere near the first unread, when ordered by date with JWZ threading.
>
> Thanks for any thoughts.

I haven't seen that, as far as I can remember. I have list messages filtered into a Maildir mailbox, and it 
seems to me that next-unread takes me to an unread message quite reliably. As I recall, when a mailbox is 
opened, the number of the first unread message, if any, is stored, and that's the message that next-unread 
takes you to. It's often not the earliest in the current sorting, but it should always be unread. After any 
message in the mailbox is read, next-unread should go to the next in the current sorting.

You're right that in a Maildir, message numbers do reflect the order in which files are read from the 
directory, which becomes quite arbitrary over time. Assigning them by age would make better sense, but on the 
face of it that would require calling stat on each filename, which could add significant overhead; perhaps 
creation times could be cached between sessions…

Suggestions?

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlkcptoACgkQH1/UtbkqdPVm7ACfe4NvVtjIwtca5PSOU5Ltr7pA
9NUAn32Saomhaa/gYJ2XVdN3ORgeLnTT
=0F+v
-----END PGP SIGNATURE-----