nneething seems badly broken as of about .29

nneething seems badly broken as of about .29

[Karl Kleinpaste]

Something very weird has happened to nneething groups in the last
couple of releases.  I first noticed it under the new 5.4.30, but it
happens under .29, too, and I haven't got anything older than that
around now, 'cuz .29 seemed so solid.  :-/

General Scenario: I routinely do C-o to save articles under various
names.  They land in the usual places, tree-style (e.g., they land in
~/News/foo/bar/some.name.i.type).  I then define nneething groups
referring to these save places, so I can refer to articles later, long
after expiration from the NNTP server.

Within the last couple of releases, a very bad side effect has taken
place.  Given several nneething groups at level 6 on startup:
 U     *: nneething+~/News/foo/bar:bar
 U     *: nneething+~/News/foo/bar/baz:baz
 U     *: nneething+~/News/foo/bar/blotch:blotch
and with nneething map files in ~/News/.nneething/, the current map
files look quite ordinary.  Hit M-g to get a group's attention, and
they generally show up with 0 articles available, because I've
(re-)read them all before.  This works all the way down to the last.
(I happen to have 6 of this flavor, but this seems incidental.)

If I hit M-g, then back up and enter the group, I get a bunch of
O-marked articles without a problem.

However, once I M-g the last one (it's always the last one), abruptly
all preceding nneething groups get confused: All the nneething map
files are rewritten to contain _only_ the contents of that last group.
Trying to re-enter any of the non-last groups fails: I try to enter it
with an argument, to get just <argument> articles, Gnus claims to be
opening, it fails and goes on to some group with genuine unread
articles.

Most importantly, if I do M-g on these (non-last) groups, they _all_
gain a viewpoint of having as many unread articles in them as are in
the last group.  And _now_, entering such a group shows me the
articles of that last group, even though the directories of the groups
in question are different from that last group!

Yow...my head hurts.

Um.  I'm fiddling with the problem as I write this, and I'm gaining a
little more understanding of the details.  Amend: The nasty effect is
seen more precisely as the most recently-opened nneething's mapfile
status being overwritten on any preceding nneething group, upon
re-M-g'ing such a preceding one, or re-entering it.  That is, it
doesn't have to be the last nneething group, it's just the last one
opened, which takes over all others preceding, when you get back to a
preceding one.

So in the example above, the exact sequence is:
	M-g on bar, show 0 articles.
	Enter bar anyway, no problem, all articles marked O.
	M-g on baz, show 0 articles.
	Enter baz, no problem, all articles marked O.
	[ but now baz has taken over, even if we don't see it yet. ]
	Back up to bar.
	Try to enter; fail to do so at all; cursor moves to the next
		group down having actual unread articles.
	Back up to bar again; M-g.
	Now if (for example) baz had 35 articles in it, and bar had
		only 10, all previously read, bar now shows 25 unread.
	Enter bar: It shows _baz's_ last 25 articles.

Ouch, ouch, ouch.

The problem is temporarily alleviated by removing the nneething map
files, exiting Gnus, and starting over.  The group parameters (G E)
are not affected: The limits of read-ness are not abused.
Unfortunately, if one has saved an article, later replied to it so as
to leave an R mark on the article, then have this whole bad effect
take place, removing the map files screws up the ordering because when
the map files are regenerated, the file-vs-number pseudoordering will
probably not be the same.

--karl