Nnimap number of unread articles estimate now correct

Nnimap number of unread articles estimate now correct

[Simon Josefsson]

Nnimap groups should now have a correct estimate for number of unread
articles.  NEWS entry:

** Unread count correct in nnimap groups.

The estimated number of unread articles in the group buffer should now
be correct for nnimap groups.  This is achieved by calling
`nnimap-fixup-unread-after-getting-new-news' from the
`gnus-setup-news-hook' (called on startup) and
gnus-after-getting-new-news-hook. (called after getting new mail).  If
you have modified those variables from the default, you may want to
add n-f-u-a-g-n-n again.  If you were happy with the estimate and want
to save some (minimal) time when getting new mail, remove the
function.

Re: Nnimap number of unread articles estimate now correct

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> Nnimap groups should now have a correct estimate for number of unread
> articles.  NEWS entry:

Maybe I should add that it is a hacky solution.  The unread number
will only be set to the correct number after getting new mail.  If
some operation causes Gnus to recalculate the unread number, it will
be incorrect until you get new mail again.  As I don't have this
problem I don't know if it is common.  Is it?  Say what operations
causes it to change and they can probably be fixed too.

I started implementing a proper fix too, and I chosed to extend the
symbol values in `gnus-active-hashtb' to hold unread count as well as
max/min values, but it seemed like alot of changes and if the hack
above works, it might cause less trouble to use it.

Re: Nnimap number of unread articles estimate now correct

[Katsumi Yamaoka]

Hi,

>>>>> In <ilulm5oo0d4.fsf@latte.josefsson.org>
>>>>>	Simon Josefsson <jas@extundo.com> wrote:

> The estimated number of unread articles in the group buffer should now
> be correct for nnimap groups.  This is achieved by calling
> `nnimap-fixup-unread-after-getting-new-news' from the
> `gnus-setup-news-hook' (called on startup) and
> gnus-after-getting-new-news-hook. (called after getting new mail).

How do pop3 users do? :-p

Opening nntp server on nntpserver...
Opening nntp server on nntpserver...done
Checking new news...done
Symbol's function definition is void: nnimap-fixup-unread-after-getting-new-news
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Nnimap number of unread articles estimate now correct

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Hi,
>
>>>>>> In <ilulm5oo0d4.fsf@latte.josefsson.org>
>>>>>>	Simon Josefsson <jas@extundo.com> wrote:
>
>> The estimated number of unread articles in the group buffer should now
>> be correct for nnimap groups.  This is achieved by calling
>> `nnimap-fixup-unread-after-getting-new-news' from the
>> `gnus-setup-news-hook' (called on startup) and
>> gnus-after-getting-new-news-hook. (called after getting new mail).
>
> How do pop3 users do? :-p
>
> Opening nntp server on nntpserver...
> Opening nntp server on nntpserver...done
> Checking new news...done
> Symbol's function definition is void: nnimap-fixup-unread-after-getting-new-news

I added an autoload cookie for the function only later.  Does it work?

Re: Nnimap number of unread articles estimate now correct

[Katsumi Yamaoka]

>>>>> In <iluadm4kzpw.fsf@latte.josefsson.org>
>>>>>	Simon Josefsson <jas@extundo.com> wrote:

>> Symbol's function definition is void: nnimap-fixup-unread-after-getting-new-news

> I added an autoload cookie for the function only later.  Does it work?

Oh, I wasn't loading gnus-load.  It works of course.   However,
is it always necessary?
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Nnimap number of unread articles estimate now correct

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <iluadm4kzpw.fsf@latte.josefsson.org>
>>>>>>	Simon Josefsson <jas@extundo.com> wrote:
>
>>> Symbol's function definition is void: nnimap-fixup-unread-after-getting-new-news
>
>> I added an autoload cookie for the function only later.  Does it work?
>
> Oh, I wasn't loading gnus-load.  It works of course.   However,
> is it always necessary?

The function doesn't do anything if there aren't any nnimap groups.
Maybe nnimap shouldn't even be loaded in this case?  Hm.  The function
could be moved from nnimap into gnus, but then it would need to access
nnimap private variables instead.  This is probably better though?

Re: Nnimap number of unread articles estimate now correct

[Clemens Fischer]

Simon Josefsson <jas@extundo.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Nnimap groups should now have a correct estimate for number of unread
>> articles.  NEWS entry:
>
> Maybe I should add that it is a hacky solution.  The unread number
> will only be set to the correct number after getting new mail.  If
> some operation causes Gnus to recalculate the unread number, it will
> be incorrect until you get new mail again.  As I don't have this
> problem I don't know if it is common.  Is it?  Say what operations
> causes it to change and they can probably be fixed too.

yes it is.  very hacky son ofabitch:  nnimap-fixup-unread-after-
getting-new-news.  it made the last few minutes of my day.  maybe you
might want to wrap it by a check whether or not this hook is even
needed, so folks without IMAP can continue using gnus!  (grummel...)

clemens

Re: Nnimap number of unread articles estimate now correct

[Kai Großjohann]

Clemens Fischer <ino@despammed.com> writes:

> it made the last few minutes of my day.  maybe you might want to
> wrap it by a check whether or not this hook is even needed, so folks
> without IMAP can continue using gnus!  (grummel...)

I think this language is inappropriate here.  It is normal for people
to make mistakes, and you know that living on the bleeding edge makes
you bleed from time to time!

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Nnimap number of unread articles estimate now correct

[Paul Jarc]

Simon Josefsson <jas@extundo.com> wrote:
> Simon Josefsson <jas@extundo.com> writes:
>> Nnimap groups should now have a correct estimate for number of unread
>> articles.  NEWS entry:

Assuming this hack is worth any extra effort (which will become wasted
when your proper fix is finished), I'd suggest telling Gnus to look
for this type of function in each of the backends in use for open
servers, rather than making it nnimap-specific.

> I started implementing a proper fix too, and I chosed to extend the
> symbol values in `gnus-active-hashtb' to hold unread count as well as
> max/min values,

I'd suggest storing the total count instead of the unread count.
Totals are what the backends can report, and given a correct total,
Gnus can calculate the correct unread count.  Since the current code
works by first calculating the total from the max and min, this would
probably be a smaller change.


paul

Re: Nnimap number of unread articles estimate now correct

[Paul Jarc]

Simon Josefsson <jas@extundo.com> wrote:
> I started implementing a proper fix too, and I chosed to extend the
> symbol values in `gnus-active-hashtb' to hold unread count as well as
> max/min values, but it seemed like alot of changes and if the hack
> above works, it might cause less trouble to use it.

Somewhat related to this, I was debugging gnus-get-unread-articles-in-group
because of nnmaildir's new wrong article counts, and I think I found a
couple of bugs.  This part doesn't handle the case where we have a
plain number inside a range list:
	;; Adjust the first element to be the same as the lower limit.
	(when (and (not (atom (car range)))
		   (< (cdar range) (car active)))
	  (setcdr (car range) (1- (car active))))
(I.e., this should be if instead of when, and it should have an else
branch.)

This part counts the number of articles in range, and then calculates
the number of unread articles by subtracting the count from the
maximum article number:
	;; Compute the number of unread articles.
	(while range
	  (setq num (+ num (- (1+ (or (and (atom (car range)) (car range))
				      (cdar range)))
			      (or (and (atom (car range)) (car range))
				  (caar range)))))
	  (setq range (cdr range)))
	(setq num (max 0 (- (cdr active) num)))))
But it should subtract the read count from (1+ (- maximum minimum))
instead, shouldn't it?

If someone can confirm my understanding, I'll fix these bugs.

It seems this code could also be made much more readable (such as by
using gnus-range-length instead of the above loop), but I didn't want
to change things out from under you while you're changing the data
structures, Simon.  Let me know if it's safe to work on this now, or
if I should wait till you're done.


paul