GNUS, IMAP, and slowness (that should be easy fixable?)

GNUS, IMAP, and slowness (that should be easy fixable?)

[Nils Klarlund]

I have used GNUS as a mail reader for a couple of years, since it
allows me to work within Emacs, where I try to "live".  (I can work
almost hands-free within Emacs.)  As such, I am very happy with it.

There is one bothersome problem, which I have not been able to fix.  I
do not believe that it is related to earlier postings in this group
about IMAP support being slow.

I would like to use GNUS in the way that standard mail readers work.
In particular, they show all mail in the group (= mail folder),
whether read or unread, and an operation check-mail updates the group
in unit time, adding new mail (i.e. in time that is not proportional
to the number of mail in the group, but a constant).

In GNUS there are only two options for updating mail as far as I can
tell:

	(gnus-summary-rescan-group t)

which does the job except that the time it takes to execute this
command is proportional to the size of the group with imap.  (The time
is spent fetching headers according to the message printed by GNUS.)
The other option is

	(gnus-summary-rescan-group)

which is much faster since it fetches the headers only for all unread
mail (which happens to include new mail).  This method is also
deficient since it does not limit itself to new mail.  Worse, and at
least this should be fixable I would imagine, all unread mail in the
group is now not shown anymore.  This behavior is inconsistent with
standard user interfaces of mail readers (and not workable in practice
I believe).

I would appreciate any help the GNUS specialists might be able to
provide.

/Nils

PS: my cache settings are:

       (setq gnus-use-cache t)
       (setq gnus-cache-directory "c:/klarlund/Mail/cache/")
       (setq gnus-cache-enter-articles '(ticked dormant read unread))
       (setq gnus-cache-remove-articles nil)
       (setq gnus-cacheable-groups "^nnimap")

Re: GNUS, IMAP, and slowness (that should be easy fixable?)

[Kai Großjohann]

klarlund@research.att.com (Nils Klarlund) writes:

> I have used GNUS as a mail reader for a couple of years, since it
> allows me to work within Emacs, where I try to "live".  (I can work
> almost hands-free within Emacs.)  As such, I am very happy with it.

Please try Gnus.  GNUS is really really outdated.  Emacs 21 comes
with Gnus 5.9 and XEmacs has Gnus 5.8.8...

> There is one bothersome problem, which I have not been able to fix.  I
> do not believe that it is related to earlier postings in this group
> about IMAP support being slow.
>
> I would like to use GNUS in the way that standard mail readers work.
> In particular, they show all mail in the group (= mail folder),
> whether read or unread, and an operation check-mail updates the group
> in unit time, adding new mail (i.e. in time that is not proportional
> to the number of mail in the group, but a constant).

If you install Oort Gnus from www.gnus.org, then you get the command
`/ N' which might do what you want.  (It still takes O(n) time, where
n is the number of new messages.  But presumably, you didn't mean
that O(1) that literally...)
-- 
Ambibibentists unite!

Re: GNUS, IMAP, and slowness (that should be easy fixable?)

[Tony E. Bennett]

klarlund@research.att.com (Nils Klarlund) writes:

> I would like to use GNUS in the way that standard mail readers work.
> In particular, they show all mail in the group (= mail folder),
> whether read or unread, and an operation check-mail updates the group
> in unit time, adding new mail (i.e. in time that is not proportional
> to the number of mail in the group, but a constant).
>
> In GNUS there are only two options for updating mail as far as I can
> tell:
>
> 	(gnus-summary-rescan-group t)
>
> which does the job except that the time it takes to execute this
> command is proportional to the size of the group with imap.  (The time
> is spent fetching headers according to the message printed by GNUS.)
> The other option is
>
> 	(gnus-summary-rescan-group)
>
> which is much faster since it fetches the headers only for all unread
> mail (which happens to include new mail).  This method is also
> deficient since it does not limit itself to new mail.  Worse, and at
> least this should be fixable I would imagine, all unread mail in the
> group is now not shown anymore.  This behavior is inconsistent with
> standard user interfaces of mail readers (and not workable in practice
> I believe).

I had some of the same issues.  This is what I bind to "g" in
summary mode.  I do not have it automatically running, however.

(defun my-gnus-summary-rescan-group (&optional heavy)
  "Rescan group; go to first unread msg."
  (interactive "P")
  (if heavy
      ;; use heavy handed one which updates the server's "read" article list
      (gnus-summary-rescan-group)

    ;; lightweight, doesn't redo the summary buffer

    ;; First, update server
    (gnus-summary-update-info)
    (gnus-summary-insert-new-articles))

  ;; select new article or last article, if no unread articles
  (or (gnus-summary-first-unread-subject)
      (progn
        (goto-char (point-max))
        (previous-line 1))))


-- 
--tony