Losing `expirable' marks in nnimap groups

Losing `expirable' marks in nnimap groups

[Kai Großjohann]

I enter a group, mark the last couple of messages as expirable, hit
M-g.  The messages are back, not marked as expirable anymore.  (They
are not marked as read, either.)

Is anyone seeing this?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Losing `expirable' marks in nnimap groups

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I enter a group, mark the last couple of messages as expirable, hit
> M-g.  The messages are back, not marked as expirable anymore.  (They
> are not marked as read, either.)
>
> Is anyone seeing this?

Not me.  When I hit M-g the articles disappears, and when I quit the
group and enter it again using C-u g I can see them, marked as E.

Re: Losing `expirable' marks in nnimap groups

[Dan Christensen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I enter a group, mark the last couple of messages as expirable, hit
> M-g.  The messages are back, not marked as expirable anymore.  (They
> are not marked as read, either.)
>
> Is anyone seeing this?

Yes, I see it too, with:

* OK Microsoft Exchange 2000 IMAP4rev1 server version 6.0.4712.0 (SATURN.pi.local) ready.

-- 
Dan Christensen
jdc@uwo.ca

Re: Losing `expirable' marks in nnimap groups

[Simon Josefsson]

Dan Christensen <jdc+news@uwo.ca> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> I enter a group, mark the last couple of messages as expirable, hit
>> M-g.  The messages are back, not marked as expirable anymore.  (They
>> are not marked as read, either.)
>>
>> Is anyone seeing this?
>
> Yes, I see it too, with:

What's the *imap-log* output when this happen?

Re: Losing `expirable' marks in nnimap groups

[Wes Hardaker]

>>>>> On Fri, 05 Jul 2002 16:14:45 +0200, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai  Großjohann) said:

Kai> I enter a group, mark the last couple of messages as expirable,
Kai> hit M-g.  The messages are back, not marked as expirable anymore.
Kai> (They are not marked as read, either.)

Kai> Is anyone seeing this?

I've seen similar things when trying to use the agent with nnimap.
Occasionally, after I re-synchronize the flags I loose all the E
marks.  (and no, no other mail reader has touched the folder in the
mean time)

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Losing `expirable' marks in nnimap groups

[Dan Christensen]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Simon Josefsson <jas@extundo.com> writes:

> Dan Christensen <jdc+news@uwo.ca> writes:
>
>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>>
>>> I enter a group, mark the last couple of messages as expirable, hit
>>> M-g.  The messages are back, not marked as expirable anymore.  (They
>>> are not marked as read, either.)
>>>
>>> Is anyone seeing this?
>>
>> Yes, I see it too, with:
>
> What's the *imap-log* output when this happen?

Hmm, I can't reproduce this anymore.  I may have been remembering
wrong.  Instead, let me mention some other things.

1) If I send one mail message to my imap account, Gnus will think
   there are three unread messages in my INBOX.  In general, Gnus is
   off by a factor of three.  A copy of the *imap-log* buffer is
   below.  I wouldn't be surprised if this is something weird about
   the server I'm accessing.

2) I have two machines each running Gnus, and both access the imap
   server.  If I delete articles in one copy of Gnus, then start the
   other copy, it thinks there are more unread articles than there
   really are.

3) Similar, if I mark articles as expirable on one machine, and then
   start Gnus on the other, it thinks the articles are just marked
   as read, not expired.  Maybe this is just how nnimap works, but
   a quick glance through the documentation didn't find this.

4) The nnimap docs say:

`nnimap-expunge-on-close'
     ... when you delete a article in Gnus (with `G DEL' or
     similar).

   Should that be `B DEL'?

5) The nnimap docs say:

`nnimap-importantize-dormant'
     If non-nil, marks dormant articles as ticked (as well), for other
     IMAP clients. Within Gnus, dormant articles will naturally still
     (only) be marked as ticked.  
                         ^^^^^^

    ticked or dormant?

    Also, the docs should say what the default is.

Dan


[-- Attachment #2: imap-log1 --]
[-- Type: application/octet-stream, Size: 4478 bytes --]

* OK Microsoft Exchange 2000 IMAP4rev1 server version 6.0.4712.0 (SATURN.pi.local) ready.
1 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LITERAL+ UIDPLUS CHILDREN AUTH=NTLM
1 OK CAPABILITY completed.
2 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LITERAL+ UIDPLUS CHILDREN AUTH=NTLM
2 OK CAPABILITY completed.
3 LOGIN "dchristensen" "password"
3 OK LOGIN completed.
4 STATUS "Deleted Items" (uidnext)
5 STATUS "Sent Items" (uidnext)
6 STATUS "Outbox" (uidnext)
7 STATUS "INBOX" (uidnext)
8 STATUS "Drafts" (uidnext)
9 EXAMINE "Drafts"
* STATUS "Deleted Items" (UIDNEXT 1)
4 OK STATUS completed.
* STATUS "Sent Items" (UIDNEXT 42)
5 OK STATUS completed.
* STATUS Outbox (UIDNEXT 79)
6 OK STATUS completed.
* STATUS INBOX (UIDNEXT 248)
7 OK STATUS completed.
* STATUS Drafts (UIDNEXT 1)
8 OK STATUS completed.
* 0 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UIDVALIDITY 3113] UIDVALIDITY value
9 OK [READ-ONLY] EXAMINE completed.
10 EXAMINE "INBOX"
* 2 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 2] Is the first unseen message
* OK [UIDVALIDITY 3100] UIDVALIDITY value
10 OK [READ-ONLY] EXAMINE completed.
11 FETCH 1,* UID
* 1 FETCH (UID 244)
* 2 FETCH (UID 247)
11 OK FETCH completed.
12 STATUS "INBOX" (uidnext)
* STATUS INBOX (UIDNEXT 248)
12 OK STATUS completed.
13 EXAMINE "Outbox"
* 0 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UIDVALIDITY 3101] UIDVALIDITY value
13 OK [READ-ONLY] EXAMINE completed.
14 STATUS "Outbox" (uidnext)
* STATUS Outbox (UIDNEXT 79)
14 OK STATUS completed.
15 EXAMINE "Sent Items"
* 0 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UIDVALIDITY 3102] UIDVALIDITY value
15 OK [READ-ONLY] EXAMINE completed.
16 STATUS "Sent Items" (uidnext)
* STATUS "Sent Items" (UIDNEXT 42)
16 OK STATUS completed.
17 EXAMINE "Deleted Items"
* 0 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UIDVALIDITY 3103] UIDVALIDITY value
17 OK [READ-ONLY] EXAMINE completed.
18 STATUS "Deleted Items" (uidnext)
* STATUS "Deleted Items" (UIDNEXT 1)
18 OK STATUS completed.
19 SELECT "INBOX"
* 2 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)] Permanent flags
* OK [UNSEEN 2] Is the first unseen message
* OK [UIDVALIDITY 3100] UIDVALIDITY value
19 OK [READ-WRITE] SELECT completed.
20 UID SEARCH UNSEEN UNDELETED
* SEARCH 247
20 OK SEARCH completed.
21 UID SEARCH SEEN
* SEARCH 244
21 OK SEARCH completed.
22 UID SEARCH FLAGGED
* SEARCH
22 OK SEARCH completed.
23 UID SEARCH ANSWERED
* SEARCH
23 OK SEARCH completed.
24 UID SEARCH RECENT
* SEARCH
24 OK SEARCH completed.
25 UID FETCH 1:243,245:247 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Keywords Newsgroups)])
* 2 FETCH (UID 247 RFC822.SIZE 1962 BODY ("TEXT" "PLAIN" ("charset" "iso-8859-1") NIL NIL "QUOTED-PRINTABLE" 6 1) BODY[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Keywords Newsgroups)] {198}
Subject: testing imap
From: "Dan Christensen" <jdc@uwo.ca>
Date: Sun, 7 Jul 2002 12:50:06 -0400
Message-ID: <871yaf1o01.fsf@uwo.ca>
To: "Dan Christensen" <dchristensen@perimeterinstitute.ca>

)
25 OK FETCH completed.
26 UID STORE 245:247 +FLAGS (\Seen)
* 2 FETCH (FLAGS (\Seen) UID 247)
26 OK STORE completed.
27 EXPUNGE
* 2 EXISTS
27 OK EXPUNGE completed.
28 UID SEARCH UNSEEN UNDELETED
* SEARCH
28 OK SEARCH completed.
29 UID SEARCH SEEN
* SEARCH 244 247
29 OK SEARCH completed.
30 UID SEARCH FLAGGED
* SEARCH
30 OK SEARCH completed.
31 UID SEARCH ANSWERED
* SEARCH
31 OK SEARCH completed.
32 UID SEARCH RECENT
* SEARCH
32 OK SEARCH completed.
33 FETCH 1,* UID
* 1 FETCH (UID 244)
* 2 FETCH (UID 247)
33 OK FETCH completed.
34 EXPUNGE
* 2 EXISTS
34 OK EXPUNGE completed.
35 LOGOUT
* BYE Microsoft Exchange 2000 IMAP4rev1 server version 6.0.4712.0 signing off.
35 OK LOGOUT completed.

Re: Losing `expirable' marks in nnimap groups

[Simon Josefsson]

Dan Christensen <jdc@uwo.ca> writes:

> 1) If I send one mail message to my imap account, Gnus will think
>    there are three unread messages in my INBOX.  In general, Gnus is
>    off by a factor of three.  A copy of the *imap-log* buffer is
>    below.  I wouldn't be surprised if this is something weird about
>    the server I'm accessing.

The server has holes in the UID range, this makes Gnus' unread
estimate wrong.  Currently this is a documented feature, but hopefully
someone gets around to fixing it sometime (it really shouldn't be
difficult).

> 2) I have two machines each running Gnus, and both access the imap
>    server.  If I delete articles in one copy of Gnus, then start the
>    other copy, it thinks there are more unread articles than there
>    really are.

Same problem as 1), I think.

> 3) Similar, if I mark articles as expirable on one machine, and then
>    start Gnus on the other, it thinks the articles are just marked
>    as read, not expired.  Maybe this is just how nnimap works, but
>    a quick glance through the documentation didn't find this.

Gnus tries to set a gnus specific flag on the server on the article,
but your server didn't offer this feature so it didn't work.
(PERMANENTFLAGS was empty in your *imap-log*).

> 4) The nnimap docs say:
>
> `nnimap-expunge-on-close'
>      ... when you delete a article in Gnus (with `G DEL' or
>      similar).
>
>    Should that be `B DEL'?

Yup, fixed, thanks.

> 5) The nnimap docs say:
>
> `nnimap-importantize-dormant'
>      If non-nil, marks dormant articles as ticked (as well), for other
>      IMAP clients. Within Gnus, dormant articles will naturally still
>      (only) be marked as ticked.  
>                          ^^^^^^
>
>     ticked or dormant?
>
>     Also, the docs should say what the default is.

Dormant, yes, fixed, thanks.

Re: Losing `expirable' marks in nnimap groups

[Kai Großjohann]

Dan Christensen <jdc@uwo.ca> writes:

> Hmm, I can't reproduce this anymore.

I've also not seen lost expirable marks in the last 1 or 2 days.
Fascinating.  A Heisenbug is when the behavior is unpredictable.  So
is a Schroederbug the case where the bug goes away if you look for it?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Losing `expirable' marks in nnimap groups

[Sean Neakums]

commence  Kai Gro?johann  quotation:
> Dan Christensen <jdc@uwo.ca> writes:
> 
> > Hmm, I can't reproduce this anymore.
> 
> I've also not seen lost expirable marks in the last 1 or 2 days.
> Fascinating.  A Heisenbug is when the behavior is unpredictable.  So
> is a Schroederbug the case where the bug goes away if you look for it?

I always thought the latter definition was that of a Heisenbug.  I had
one of those once, but I've forgotten the details.  I recall it
involved some C code and gdb.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: Losing `expirable' marks in nnimap groups

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Fascinating.  A Heisenbug is when the behavior is unpredictable.  So
> is a Schroederbug the case where the bug goes away if you look for it?

No, that's a Heisenbug (at least according to the Jargon File; maybe
common usage also includes generic unpredictability).  A Schroedinbug
is complementary: it starts manifesting itself after you find it.
<URL:http://www.tuxedo.org/~esr/jargon/html/entry/heisenbug.html>
<URL:http://www.tuxedo.org/~esr/jargon/html/entry/schroedinbug.html>


paul

Re: Losing `expirable' marks in nnimap groups

[Joseph Barillari]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

>>>>> "SN" == Sean Neakums <sneakums@zork.net> writes:

    SN> commence Kai Gro?johann quotation:
    >> Dan Christensen <jdc@uwo.ca> writes:
    >> 
    >> > Hmm, I can't reproduce this anymore.
    >> 
    >> I've also not seen lost expirable marks in the last 1 or 2
    >> days.  Fascinating.  A Heisenbug is when the behavior is
    >> unpredictable.  So is a Schroederbug the case where the bug
    >> goes away if you look for it?

    SN> I always thought the latter definition was that of a
    SN> Heisenbug.  I had one of those once, but I've forgotten the
    SN> details.  I recall it involved some C code and gdb.

I'll second that. So does the Jargon File[0]:

# heisenbug /hi:'zen-buhg/ n.

# [from Heisenberg's Uncertainty Principle in quantum physics] A bug
# that disappears or alters its behavior when one attempts to probe or
# isolate it.

Conversely, a 'schroedinbug' is "A design or implementation bug in a
program that doesn't manifest until someone reading source or using
the program in an unusual way notices that it never should have
worked, at which point the program promptly stops working for
everybody until fixed."

An "unpredictable" (quoth Kai) bug is a mandelbug:

# [from the Mandelbrot set] A bug whose underlying causes are so complex
# and obscure as to make its behavior appear chaotic or even
# non-deterministic. This term implies that the speaker thinks it is a
# Bohr bug, rather than a heisenbug. See also schroedinbug.

--Joe

[0] http://www.tuxedo.org/~esr/jargon/html/The-Jargon-Lexicon-framed.html[1]

[1] Is there a gnus add-on for auto-numbering footnotes like these?
    Can one, for instance, use a LaTeX-like syntactic construct to
    indicate footnote content, and run a function to process the
    footnotes before sending the message?
    

[-- Attachment #2: Type: application/pgp-signature, Size: 258 bytes --]

Re: Losing `expirable' marks in nnimap groups

[Sean Neakums]

commence  Joseph Barillari  quotation:
> [1] Is there a gnus add-on for auto-numbering footnotes like these?
>     Can one, for instance, use a LaTeX-like syntactic construct to
>     indicate footnote content, and run a function to process the
>     footnotes before sending the message?

M-x footnote-mode

As I recall, it formats them the same as your manual style.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |