Re: Gnus v5.4.62 is released

[Hrvoje Niksic <hniksic@srce.hr>]

Jens Lautenbacher <jens@metrix.de> writes:

> > Exactly.  Which is why Gnus should provide the most palatable
> > behaviour by default.  And I still think this category includes /not/
> > creating 100K+ .newsrc.eld by default.
> 
> Disk space? 100k+? even 300k wouldn't matter.

So we differ.

> You can't be serious suggesting that it's a user friendly behaviour to
> need one time something like 10 A T

I didn't say that.  I just implied that you /can/ get the listing,
even with `gnus-read-active-file' so `some'.

> > > But it's extremely non-logical if suddenly I can't access the whole
> > > feed anymore (...)
> > 
> > Sure you can -- see above.
> 
> No you can't; see above.

What is this?  A word game?

> In some moon reader it's one keystroke to get all groups.

Then we should make it so in Gnus, if you consider it important.  Or
back out this change -- because it's already been done, you know.

> I don't care as a user if the program caches this list or not if
> it's only fast enougth. The reason that tin can just forget about
> all this is that it spends almost no time with parsing, while
> gnus....

Well, there you have it -- and that was the exact reason to change for 
`gnus-read-active-file' to default to `some'.

Maybe Gnus should read the whole active file the first time it starts
up, and save the killed list for future usage?  The obnoxious disk
space usage still remains, but I guess noone really cares these days.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.