GNUs group article counts

[Tory S. Anderson]

I have done some massive expiry work on some of my groups, to
where now an exhaustive list of messages shows something like
1100; however, when in group view and I tell it to enter the
group, it is still telling me to choose up to 10x that number. I
want to make sure I am clearing disc space and really optimizing
things; how can I make the count correct, or do I need to do
something more than expiration?

[allan gottlieb]

The problem is that the number that is 10x is calculated as

highest article number minus lowest article number

So just removing articles in the middle doesn't change it.

There is a "global" command that I used once (but forgot its name)
that eliminates the holes in the numbers.

allan

[Emanuel Berg]

torys.a...@gmail.com (Tory S. Anderson)
writes:

> I have done some massive expiry work on some
> of my groups, to where now an exhaustive list
> of messages shows something like 1100;
> however, when in group view and I tell it to
> enter the group, it is still telling me to
> choose up to 10x that number. I want to make
> sure I am clearing disc space and really
> optimizing things; how can I make the count
> correct, or do I need to do something more
> than expiration?

Well, first, it is Gnus, not "GNUs" (it is
a pun on "news" and GNU, I always thought).
There was a Gnus prior to Gnus, which was
called GNUS. Gnus was initially known as "ding"
(for "ding is not GNUS") but it didn't take.
All this obviously long before my time...

To try to answer your question, in the group
buffer, the number of *unread* articles in
a group should be indicated somewhere on the
line. Exactly where depends on you
`gnus-group-line-format' variable. You can
examine it and look for %N in the format
string. In the help, it says

%N Number of unread articles (integer)

Now, if you hit RET with point on a group, if
there are unread articles, those are what
you get.

But if there are no unread articles, then you
are prompted how many *old* articles to fetch,
as there is no such natural implication as it
is on the "unread" side of things!

And stop worrying about disc space.

--
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
- so far: 48 Blogomatic articles -

[Emanuel Berg]

allan gottlieb <gott...@nyu.edu> writes:

> The problem is that the number that is 10x is
> calculated as
>
> highest article number minus lowest
> article number
>
> So just removing articles in the middle
> doesn't change it.

Like I said, stop worrying about disc space and
the problem disappears :)

[Ted Zlatanov]

On Wed, 15 Jun 2016 17:27:20 -0400 allan gottlieb <gott...@nyu.edu> wrote:

ag> On Wed, Jun 15 2016, Tory S. Anderson wrote:
>> I have done some massive expiry work on some of my groups, to where
>> now an exhaustive list of messages shows something like 1100; however,
>> when in group view and I tell it to enter the group, it is still
>> telling me to choose up to 10x that number. I want to make sure I am
>> clearing disc space and really optimizing things; how can I make the
>> count correct, or do I need to do something more than expiration?

ag> The problem is that the number that is 10x is calculated as

ag> highest article number minus lowest article number

ag> So just removing articles in the middle doesn't change it.

ag> There is a "global" command that I used once (but forgot its name)
ag> that eliminates the holes in the numbers.

gnus-group-compact-group is an interactive compiled Lisp function in
‘gnus-group.el’.

(gnus-group-compact-group GROUP)

Compact the current group.
Compaction means removing gaps between article numbers. Hence, this
operation is only meaningful for back ends using one file per article
(e.g. nnml).

Note: currently only implemented in nnml.

HTH
Ted

[allan gottlieb]

(gnus-group-compact-group GROUP) works great. Thanks.

allan

[allan gottlieb]

As I mentioned previously gnus-group-compact-group works great for
eliminating gaps in article numbers.

I realized that, since gnus-group-compact-group copies the files, those
previously marked E might not expire before nnmail-expiry-wait days
after running gnus-group-compact-group. But that is not happening.

In my main mail group I have a large number of messages that arrived in
May and were marked E. On 16 June I ran gnus-group-compact-group.
Since nnmail-expiry-wait is 31 (see below) they should have disappeared
a few days ago but have not.

Any help would be appreciated.

allan

------------------------------------

nnmail-expiry-wait is a variable defined in `nnmail.el'.
Its value is 31
Original value was 7

-------------------------------------------------------

(gnus-summary-goto-article 1000)

selects

27-MayE [ 277: J. P. MORGAN SECURITIES] PIMCO FUNDS Important Information

-------------------------------

gottlieb@E7450-wired ~ $ ls -l ~/Mail/MAIL/1000
-rw------- 1 gottlieb gottlieb 11091 Jun 16 18:18 /home/gottlieb/Mail/MAIL/1000