Danger! Danger!

Danger! Danger!

[Lars Magne Ingebrigtsen]

It seems like Red Gnus 0.71 (and possibly previous versions as well)
is removing ticks from articles.  This has dramatic consequences if
you're using total-expiry on some of your mail groups.  Switch
automatic expiry off at once:

(setq gnus-summary-prepare-exit-hook nil)

I have yet to determine what exactly is making the ticks go away.  I
have no idea, really.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[Samuel Tardieu]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> It seems like Red Gnus 0.71 (and possibly previous versions as
Lars> well) is removing ticks from articles.  This has dramatic
Lars> consequences if you're using total-expiry on some of your mail
Lars> groups.

I can confirm this: this has been present in the last versions, and I
had to retick almost everything by hand. But since I was modifying
some of the associated packages (such as Mailcrypt or BBDB), I thought
it was my fault.

Trick: if you notice that ticks have been removed, you can still have
       a chance to retick articles in going into the group again using
       "C-u space" and ticking the articles marked with the cache mark
       (*)

 Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Danger! Danger!

[Steven L Baur]

>>>>> "Samuel" == Samuel Tardieu <sam@inf.enst.fr> writes:
>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> It seems like Red Gnus 0.71 (and possibly previous versions as
Lars> well) is removing ticks from articles.  This has dramatic
Lars> consequences if you're using total-expiry on some of your mail
Lars> groups.

Samuel> I can confirm this: this has been present in the last versions, and I
Samuel> had to retick almost everything by hand.

Ouch.  I'm noticing a different effect.  I'm having some messages that
are counted as unread in the *Group* buffer disappear into the ether.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

Re: Danger! Danger!

[David Moore]

Steven L Baur <steve@miranova.com> writes:

> >>>>> "Samuel" == Samuel Tardieu <sam@inf.enst.fr> writes:
> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> Lars> It seems like Red Gnus 0.71 (and possibly previous versions as
> Lars> well) is removing ticks from articles.  This has dramatic
> Lars> consequences if you're using total-expiry on some of your mail
> Lars> groups.
> 
> Samuel> I can confirm this: this has been present in the last versions, and I
> Samuel> had to retick almost everything by hand.
> 
> Ouch.  I'm noticing a different effect.  I'm having some messages that
> are counted as unread in the *Group* buffer disappear into the ether.

	I used to notice this occasionally, and thought it was related
to crossposts or duplication or NoCeM.  But in 0.70 it's happening _a
lot_.  Also now sometimes when I enter a group, read all of the articles
and exit, the group buffer will say '1' instead of '0', but when I go
into it, nothing's there of course.

	But definitely with 0.70, I'm seeing that if I Gcc myself
something and also get the same message via mail, the odds seem high of
that thing showing up as 'already read'.  But I think it's also
happening with other incoming mail, so it's probably not just a gcc
problem.

	nnmail-split-history and the 'j' command in the summary window
helps me track down these errant messages, but I might be missing a lot
too.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: Danger! Danger!

[Samuel Tardieu]

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> Ouch.  I'm noticing a different effect.  I'm having some
Steven> messages that are counted as unread in the *Group* buffer
Steven> disappear into the ether.

Maybe yet another hint: I've also noticed that selecting a message in
the Summary buffer (that is going on another message than the current
one and pressing 'space') often gives me another one!

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Danger! Danger!

[Per Abrahamsen]

Try upgrading w3, it looks like it uses a widget from an old version
of the widget library.

Re: Danger! Danger!

[Sudish Joseph]

In article <rvpw108y24.fsf@sdnp5.ucsd.edu>,
David Moore <dmoore@UCSD.EDU> writes:
> Steven L Baur <steve@miranova.com> writes:
>> Ouch.  I'm noticing a different effect.  I'm having some messages that
>> are counted as unread in the *Group* buffer disappear into the ether.

> 	I used to notice this occasionally, and thought it was related
> to crossposts or duplication or NoCeM.  But in 0.70 it's happening _a
> lot_.  Also now sometimes when I enter a group, read all of the articles
> and exit, the group buffer will say '1' instead of '0', but when I go
> into it, nothing's there of course.

I've been seeing this since 0.60.  It didn't happen prior to 0.56.  In
private mail with Lars, I convinced myself that Gnus was getting
confused when the head article was cancelled.  I'm no longer sure of
this.  I just had a 7 article group present 5 articles on entering.

Also, it'd be real neat if M-RET behaved like C-u SPC.  I.e., it
should not look at ticked/dormant article numbers.  Just fetching the
last n articles and presenting them w/o *any* further processing would
be _extremely_ useful.  As things stand, port 119 is the only way we
have of checking stuff; too time-consuming to be a real option for me.


BTW, the gnus-emphasise stuff simply rewlz.  Makes a huge difference
when reading and is easy to create when writing.  No hope of ever
making this standard, but it'd have been a really nifty, lightweight
mechanism that works on all UA's.

-Sudish

Re: Danger! Danger!

[David Moore]

Samuel Tardieu <sam@inf.enst.fr> writes:
> Maybe yet another hint: I've also noticed that selecting a message in
> the Summary buffer (that is going on another message than the current
> one and pressing 'space') often gives me another one!

	A variety of things seem to have broken in the summary buffer
after the rewrite in 0.70 to not use the text-propery-any method.  Now I
wonder if my bug reports on them got lost. ;-) Unfortunately no fixes
provided with the reports.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: Danger! Danger!

[Per Abrahamsen]

>>>>> "SJ" == Sudish Joseph <sudish@mindspring.com> writes:

SJ> I've been seeing this since 0.60.  It didn't happen prior to 0.56.  In
SJ> private mail with Lars, I convinced myself that Gnus was getting
SJ> confused when the head article was cancelled.  I'm no longer sure of
SJ> this.  I just had a 7 article group present 5 articles on entering.

Do you use dormant articles?  I use many dormant articles, and have
had the problem of some unread articles missing from the summary more
often than not.  I can usually work around it by explicitly requesting
the number of articles to retrieve.  I.e. if the group buffer say

	12: gnu.misc.discuss

I may get 8 articles in the summary buffer.  Leaving the group will
give me a group display of
	
         4: gnu.misc.discuss

Reentering gnu.misc.discuss then gives me a buffer with all my dormant
articles.  However, if I enter the buffer with `12 SPC' I usually get
all the 12 new articles.

Removing the dormant articles from the group info solved the problem,
so I suspect it is related to that.

Re: Danger! Danger!

[Steven L Baur]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
>>>>> "SJ" == Sudish Joseph <sudish@mindspring.com> writes:

SJ> I've been seeing this since 0.60.  It didn't happen prior to 0.56.
SJ> In private mail with Lars, I convinced myself that Gnus was
SJ> getting confused when the head article was cancelled.  I'm no
SJ> longer sure of this.  I just had a 7 article group present 5
SJ> articles on entering.

Per> Do you use dormant articles?  I use many dormant articles, and have
Per> had the problem of some unread articles missing from the summary more
Per> often than not.

Not usually, but I do use them in the group where I first noticed this
problem.

Per> Removing the dormant articles from the group info solved the problem,
Per> so I suspect it is related to that.

That didn't work for me.  Is there anything else you did?

I didn't notice it until quite recently, and in the group where I did
first notice it, it gains one phantom message everytime I read the
group with more than 1 unread message in it. :-(
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

Re: Danger! Danger!

[Steven L Baur]

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> Also, it'd be real neat if M-RET behaved like C-u SPC.  I.e.,
Sudish> it should not look at ticked/dormant article numbers.  Just
Sudish> fetching the last n articles and presenting them w/o *any*
Sudish> further processing would be _extremely_ useful.

I agree.

Sudish> As things stand, port 119 is the only way we have of checking
Sudish> stuff; too time-consuming to be a real option for me.

Which is not a real solution as the problem appears in nnml groups.
It's scary to think of unread email that disappears in this fashion.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

Re: Danger! Danger!

[Sudish Joseph]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Do you use dormant articles?

No.

-Sudish

Re: Danger! Danger!

[Sudish Joseph]

In article <m2d8x0bhhm.fsf@altair.xemacs.org>,
Steven L Baur <steve@miranova.com> writes:
> Which is not a real solution as the problem appears in nnml groups.
> It's scary to think of unread email that disappears in this fashion.

Hmm.  The only time I've seen this happen in an nnml group was when I
had two matching rules for one group in an &'ed nnmail-split-fancy --
it created two physical copies of the message but displayed just one.

Hrm.  Let's try that again.  *Group* buffer: 2 messages, *Summary*: 1
displayed, physical dir: 2 files, nnmail-split-fancy: 2 rules.

This is probably a non-feature in nnmail-s-f.  I.e., the bug was in my
usage, but it'd be neat if nnmail-s-f eliminated dups, I hate using
long regexps that are OR'ed at the root.

However, it *is* incorrect of Gnus not to let you know that it came
across a duplicate msgid (i assume this is what caused this particular
prob.).

-Sudish

Re: Danger! Danger!

[Steven L Baur]

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> In article <m2d8x0bhhm.fsf@altair.xemacs.org>,
Sudish> Steven L Baur <steve@miranova.com> writes:

sb> Which is not a real solution as the problem appears in nnml groups.
sb> It's scary to think of unread email that disappears in this fashion.

Sudish> Hmm.  The only time I've seen this happen in an nnml group was
Sudish> when I had two matching rules for one group in an &'ed
Sudish> nnmail-split-fancy -- it created two physical copies of the
Sudish> message but displayed just one.
 ...
Sudish> However, it *is* incorrect of Gnus not to let you know that it came
Sudish> across a duplicate msgid (i assume this is what caused this particular
Sudish> prob.).

Yes.  What I expect in that case is something like:
Gnus-Warning: This is a duplication of message <wyd97su7zn.fsf@neuromancer.ese-metz.fr>

That is not what is happening to me.  Lars identified one of my
phantom messages and a grep confirms that it does not have a
duplicate Message-ID.

One bit of strangeness is that in Red Gnus v0.57, v0.69-v0.71
attempting to select this phantom unread message results in what looks
like an infinite loop.  When I tried the same thing with 5.2.40, I got
a `cannot select' message.  (The message is present on disk, and it is
present in the .overview file).
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

David Moore <dmoore@UCSD.EDU> writes:

> 	But definitely with 0.70, I'm seeing that if I Gcc myself
> something and also get the same message via mail, the odds seem high of
> that thing showing up as 'already read'.  But I think it's also
> happening with other incoming mail, so it's probably not just a gcc
> problem.

Hm.  You're not using duplicate suppression or something like that? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

Sudish Joseph <sudish@mindspring.com> writes:

> Also, it'd be real neat if M-RET behaved like C-u SPC.  I.e., it
> should not look at ticked/dormant article numbers.  Just fetching the
> last n articles and presenting them w/o *any* further processing would
> be _extremely_ useful.

Yes, it would be useful.  Threading should probably be switched off as
well.  I don't want to use `M-RET' for this, though -- `M-C-RET' seems
like a nice choice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> Yes.  What I expect in that case is something like:
> Gnus-Warning: This is a duplication of message <wyd97su7zn.fsf@neuromancer.ese-metz.fr>

This works, as far as I can tell.  nnmail does discover duplicate
mails. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

David Moore <dmoore@UCSD.EDU> writes:

> 	A variety of things seem to have broken in the summary buffer
> after the rewrite in 0.70 to not use the text-propery-any method.  Now I
> wonder if my bug reports on them got lost. ;-)

Nope; just haven't had time to do anything about it yet.  

This is probably totally unrelated to the "missing ticks" problem,
which is probably totally unrelated to the "phantom article" problem.

*sigh*  You can tell that we're nearing a real release -- you get all
sorts of serious bugs popping up.  :-)

I may have found out what the "missing ticks" problem was --
`gnus-summary-update-info' switched buffers, which isn't a good idea.
Fix in Red Gnus v0.72.  I still have no idea what the "phantom
article" thing is about.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[David Moore]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> David Moore <dmoore@UCSD.EDU> writes:
> 
> > 	But definitely with 0.70, I'm seeing that if I Gcc myself
> > something and also get the same message via mail, the odds seem high of
> > that thing showing up as 'already read'.  But I think it's also
> > happening with other incoming mail, so it's probably not just a gcc
> > problem.
> 
> Hm.  You're not using duplicate suppression or something like that? 

	I file my detected duplicates into a folder that I clear
manually, currently.  What happens is that if I gcc myself and also get
a copy, that often now, the real copy will arrive via email and be filed
into the correct group (ie, not the duplicate group), but will have the
read mark set (or something).  Maybe I can see if I can make this
reproducable.

	Previous versions would not hide the real copy of message, ie,
both would show up in the summary listing.  Now I do a unix 'from', se I
have the message.  I do 'M-2 g', I watch it file.  Often the unread
counter goes up by the appropriate amount.  I go into the group, and
that message isn't shown to me.  I use nnmail-split-history to get the
article number, use 'j' to go to it.  And it's there, but has been
marked as read for some reason.

	But maybe this is related to some other more generic hiding of
messages, it's hard to tell if I've missed mail or not...which is a bit
disturbing. 

	Maybe something in the code is using the wrong active range to
truncate the unread/ticked/etc lists.  That could explain all of these
problems, although doesn't make it easy to find.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: Danger! Danger!

[Mark Boyns]

David Moore <dmoore@UCSD.EDU> writes:

> 	I file my detected duplicates into a folder that I clear
> manually, currently.  What happens is that if I gcc myself and also get
> a copy, that often now, the real copy will arrive via email and be filed
> into the correct group (ie, not the duplicate group), but will have the
> read mark set (or something).  Maybe I can see if I can make this
> reproducable.

I think I noticed this problem yesterday.  I sent a message to myself
and Gcc it to nnml:mail.boyns.  (which is where the sent message will
also go) When I type M-g on nnml:mail.boyns, the message I sent to
myself is read from the spool and the group buffer says there are 2
new messages.  When I enter nnml:mail.boyns only 1 article is
displayed.

This is reproducible.

Re: Danger! Danger!

[Steinar Bang]

>>>>> Steven L Baur <steve@miranova.com>:

> Ouch.  I'm noticing a different effect.  I'm having some messages that
> are counted as unread in the *Group* buffer disappear into the ether.

I had this happening in 0.60.  Haven't used 0.71 (my next step
upgrade) long enough to determine if I have the same behaviour here.

It *might* have to do with spam beeing scored into oblivion, but for a
while here, it happened too often to be that... I think...

If I see it, from where should I send the bug report?  From inside the
group?  From *Groups*?  Or doesn't it matter?


- Steinar

Re: Danger! Danger!

[Steinar Bang]

>>>>> David Moore <dmoore@UCSD.EDU>:

> 	I used to notice this occasionally, and thought it was related
> to crossposts or duplication or NoCeM.  But in 0.70 it's happening _a
> lot_.  Also now sometimes when I enter a group, read all of the articles
> and exit, the group buffer will say '1' instead of '0', but when I go
> into it, nothing's there of course.

In addition
	C-u some-number SPC
in *Groups* doesn't seem to be fetching the some-number last articles
(this behaviour observed in 0.60).


- Steinar

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> If I see it, from where should I send the bug report?  From inside the
> group?  From *Groups*?  Or doesn't it matter?

It doesn't matter.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[Hrvoje Niksic]

Lars Magne Ingebrigtsen (larsi@ifi.uio.no) wrote:
> Yes, it would be useful.  Threading should probably be switched off as
> well.  I don't want to use `M-RET' for this, though -- `M-C-RET' seems
> like a nice choice.

Not to me.  You can't get it on tty-s.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Hocemo 101-icu!
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen (larsi@ifi.uio.no) wrote:
> > Yes, it would be useful.  Threading should probably be switched off as
> > well.  I don't want to use `M-RET' for this, though -- `M-C-RET' seems
> > like a nice choice.
> 
> Not to me.  You can't get it on tty-s.

It's not a command you'll be using very often, so you can just say
`M-x gnus-group-select-group-ephemerally'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Danger! Danger!

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> I don't want to use `M-RET' for this, though -- `M-C-RET' seems
> like a nice choice.

Please don't use fictitious control sequences.  RET is already a
control character, and X' ability to "controlify" any keystroke is not
a feature.  Bland tty use (a substantial portion of my Gnus use is via
telnet and rlogin) cannot generate "C-RET".

Re: Danger! Danger!

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> It's not a command you'll be using very often, so you can just say
> `M-x gnus-group-select-group-ephemerally'.

Dilbert, 01 February 1994:

Saint Dogbert seeks out technology that has
been possessed by the demons of stupidity.
He happens across a software developer.
[Developer:]
"I'll make the command easy to remember,
 like `Ctrl-Alt-F4-Del'.
 And if they forget that they can just
 edit the source code in COMMAND.COM.
 Perfect."
[Dogbert, waving saintly scepter at developer:]
"Out!  Out!"

Now, far be it from me to suggest that Lars has been possessed by the
demons of stupidity.  Hardly.  But putting a useful command on a key
that is entirely unavailable to non-X users...well...

Re: Danger! Danger!

[Steven L Baur]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> Steven L Baur <steve@miranova.com> writes:
sb> Yes.  What I expect in that case is something like:
sb> Gnus-Warning: This is a duplication of message <wyd97su7zn.fsf@neuromancer.ese-metz.fr>

Lars> This works, as far as I can tell.  nnmail does discover duplicate
Lars> mails. 

Yes it does appear to work.

Your diagnosis of a threading loop was correct for solving the phantom
unread problem for me.  I turned off threading and all the missing
messages appeared. :-)
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

Re: Danger! Danger!

[Lars Magne Ingebrigtsen]

David Moore <dmoore@UCSD.EDU> writes:

> 	Previous versions would not hide the real copy of message, ie,
> both would show up in the summary listing. 

Hm.  The problem is that Gcc'd copies aren't passed through the
splitting process, so the Message-ID's aren't registered anywhere, and
the "real" messages will end up with the same Message-ID as the Gcc'd
copies...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen