utterly bogus "How many articles from ... (available ..., default ...)"

utterly bogus "How many articles from ... (available ..., default ...)"

[jidanni]

You know, this line
   How many articles from mail.debianbugs (available 388, default 200):
is misleading.

One sees it when about to enter a group in which all articles are
already read.

You see I often use
   E runs the command gnus-summary-mark-as-expirable,

So in fact all that really are in that directory are

$ ls -vx
9    22   27   28   30	 31   37   46	81   90  93  96  123  135  181	216  217  218  253  254
258  276  300  302  356  357  394  395	396

Which agrees with the overview file.

$ cut -f 1 .overview > /tmp/s
$ ls -v|diff - /tmp/s
$

Ha! 396 - 9 ~= 388. It just "never expected" there might be holes in the middle.

It just assumes there aren't. It doesn't know,
http://www.youtube.com/watch?v=lQ57rtIv7kk&p=6E40919035151385

Another big problem is OK, given there are
$ ls |wc -l
29
messages there, one might expect if I answer "29" when asked How many
articles, that's what I'll get.

However of course I only get 3. As there are only 3 articles actually
there within the 29 latest supposed existing articles.

If I really want to see all 29 articles, I had better type 396 when
asked, or the easier to type 444, 555, etc.

However the common person doesn't know that and his older articles now
become inaccessible to him, even though there are there on the disk.

So you gnus fellow have a lot of fixing to do.

I bet you are using a newsgroup mentality carried over to groups where
message removal is possible.

By the way, here is my .newsrc.eld section,

  ("nnml:mail.debianbugs" 3
   ((1 . 396))
   ((seen (1 . 396)) (save 96 395) (expire (394 . 396)) (reply 28 31 81 90 93 123 181 (253 . 254) 258 276 302 (356 . 357) (394 . 395))) "nnml:"
   ((timestamp 19957 62151)))

And the .marks file.

((expire 355 (358 . 396)) (reply 28 31 81 90 93 105 (114 . 118) (122 .
123) (131 . 132) 134 136 138 146 149 (153 . 154) 158 163 177 (181 . 186)
(188 . 189) 191 195 198 (202 . 204) (224 . 225) 230 232 (244 . 246) (253
. 254) 258 276 302 340 344 (347 . 348) (350 . 351) (355 . 362) 368 371
374 383 (385 . 388) 391 (394 . 395)) (save 96 103 118 150 (196 . 197)
362 395) (read (1 . 347)))

My configuration files are on http://jidanni.org/comp/configuration/

And rest assured I use very new gnus,
emacs-snapshot:
  Installed: 1:20110608-1

Re: utterly bogus "How many articles from ... (available ..., default ...)"

[Lars Magne Ingebrigtsen]

jidanni@jidanni.org writes:

> You know, this line
>    How many articles from mail.debianbugs (available 388, default 200):
> is misleading.

388 is the max possible number of articles, which is all the info Gnus
has access to.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: utterly bogus "How many articles from ... (available ..., default ...)"

[Peter Münster]

On Sun, Jun 26 2011, Lars Magne Ingebrigtsen wrote:

> jidanni@jidanni.org writes:
>
>> You know, this line
>>    How many articles from mail.debianbugs (available 388, default 200):
>> is misleading.
>
> 388 is the max possible number of articles, which is all the info Gnus
> has access to.

I think, the OP suggests, that the back-end should provide more or better
information, if possible. The nnml back-end for example could provide the
real number of available articles. When this information is not evaluable
(nntp), then Gnus could fall back to (n = 1 + max - min) as it does today.

-- 
           Peter

Re: utterly bogus "How many articles from ... (available ..., default ...)"

[Lars Magne Ingebrigtsen]

pmlists@free.fr (Peter Münster) writes:

> I think, the OP suggests, that the back-end should provide more or better
> information, if possible.

Yes, that would be nice.  However, this particular user has reported the
same thing, like, four thousand times now, and there's just so many
times that I feel like repeating the same thing.

Doing something about this is going to happen in the next Gnus
development cycle.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: utterly bogus "How many articles from ... (available ..., default ...)"

[jidanni]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
LMI> pmlists@free.fr (Peter Münster) writes:

>> I think, the OP suggests, that the back-end should provide more or better
>> information, if possible.

LMI> Yes, that would be nice.  However, this particular user has reported the
LMI> same thing, like, four thousand times now, and there's just so many
LMI> times that I feel like repeating the same thing.

No. This is the first time I discovered this particular problem.

LMI> Doing something about this is going to happen in the next Gnus
LMI> development cycle.

I am saying that you are taking a list with many holes in it, and
communicating to the user as if there was always not one single hole in
it.

You get the two edges correct, but ignore the fact that 99% of the items
in between them might be missing.