Subject: Re: TAB does not detect new messages in incoming folders

From: "Pierre Rocher" <[email-masked]>
Date: Fri, 11 Jan 2002 23:37:05 +0000

Hi,

Thanks to Eduardo suggestion to use _IMAPSTATUS_ to examine the message 
status, I've identified a couple of bugs and got one of them fixed.  The 
original problem:

 > hitting TAB when cursor is at the last message, it loops thru
 > the folders "Checking XXX for recent messages" and eventually "No
 > more incoming folders" is displayed.  However, it does not flag
 > or display messages with new flag in any of the folders there.

IMAPSTATUS provides the clue.  Further tests suggest with the detailed 
status of IMAPSTATUS [N,R,U], TAB does find messages with the N flag, but 
not R nor U.  There are two bugs:

Bug 1: TAB only finds messages in the incoming collection folders with the 
"N" status only, where it should detect both "N" and "U" statuses.

Bug 2: This is more obscure - messages which should be tagged with the "N" 
flag is tagged with the "U" flag instead.  There is only one time where I 
saw a filtered msg folder gets the "N" status and TAB detected it. Cannot 
reproduce that again. Initially, I suspect the checking of folders resulted 
from the TAB implicitly does an open, causing msgs with N status to become 
U.  However, with a filter-to folder already opened (current folder) and a 
new msg is filtered into it, the status is U immediately!

The combination of bug 1 and 2 render the TAB key rather useless for 
checking new messages other than INBOX (for POP3 at least). The fix for Bug 
1 is included below.  I've built (what a nightmare) my own 4.44a version and 
tested this on my solaris to be working as I want.  Bug 2 doesn't bother me 
since the message will be marked UNSEEN anyway, and TAB detects UNSEEN ones.

% diff /usr/local/pine/pine4.44/pine/folder.c my/folder.c
7098c7098,7099
<                !context_status(cntxt, stream, f->name, SA_RECENT)){
---
>                !context_status(cntxt, stream, f->name,
>                                  SA_RECENT | SA_UNSEEN)){
7104,7105c7105,7107
<             rv = ((mm_status_result.flags & SA_RECENT)
<                   && (*find_recent = mm_status_result.recent))
---
>             rv = ((mm_status_result.flags & (SA_RECENT | SA_UNSEEN))
>                   && (*find_recent =
>                         (mm_status_result.recent | 
>mm_status_result.unseen)))

I wonder if SA_RECENT is even needed, but I don't really care since the 
executable works the way I wanted.  Hope this will be fixed in next version, 
or someone grab it as a contrib patch.

Best regards,
P.Rocher

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: Eduardo Chappa <[email-masked]>
Date: Fri, 11 Jan 2002 16:19:45 -0800 (PST)

*** Pierre Rocher ([email-masked]) wrote in the pine-info list today:

:) IMAPSTATUS provides the clue.  Further tests suggest with the detailed
:) status of IMAPSTATUS [N,R,U], TAB does find messages with the N flag, but
:) not R nor U.  There are two bugs:
:)
:) Bug 1: TAB only finds messages in the incoming collection folders with the
:) "N" status only, where it should detect both "N" and "U" statuses.

Hello Pierre,

  Tab only tries to find messages with the "N" flag. Messages with the "U"
flag are messages that were in the folder the last time it was opened,
but you either did not read them or decided to read them and flag them as
new again. If you close that folder (without deleting that message), the
next time it is opened you will see it marked with a "U".

  From here it follows that TAB is working correctly in your case, because
IMAPSTATUS is telling you that somehow between the moment that the message
was saved in the folder and the moment that TAB is doing the check, the
folder was read or it was touched by some other process. It may be that by
saving the files, the folder is considered to be opened. This should be
the bug, I use Pine filters to filter messages from INBOX to an incoming
folder and do not have this problem.

-- 
Eduardo
http://www.math.washington.edu/~chappa/pine/