Re: Faster, lolcat. Faster!

[David Engster <deng@randomsample.de>]

Frank Schmitt writes:
> Julien Danjou <julien@danjou.info> writes:
>
>> On Thu, Sep 02 2010, Ted Zlatanov wrote: 
>>
>>> In the "too slow to be done properly" category are the unread/unseen
>>> nnimap counts which as you know are usually inaccurate.  We've had
>>> patches over the years but I don't think anyone has actually solved
>>> the problem. 
>>
>> +1
>>
>> The way I fix it is by running M-g over all the group.
>> Which is even slower.
>
> me2. This really, really sucks.

This was last discussed here:

http://article.gmane.org/gmane.emacs.gnus.general/67238

The idea was to make Gnus able to see the whole list of available
article numbers on the server. Currently, due to its roots in NNTP, it
only uses the active information (lowest . highest). 

Vitaly had some patches which extended gnus-active to either be a cons
or a list, containing the old active information or the full list of
article numbers, resp. My opinion was that it would be better to leave
gnus-active alone and introduce a new function in the back end API for
this. In fact, there already is an (more or less undocumented) function
`gnus-request-group-articles', which is implemented for NNTP. However,
it's straightforward to do for nnimap, for example:

(deffoo nnimap-request-group-articles (group &optional server)
  (nnimap-possibly-change-group group server)
  (let ((articles (with-current-buffer nnimap-server-buffer
		    (imap-search "ALL"))))
    (if articles
      (with-current-buffer nntp-server-buffer
	(erase-buffer)
	(insert 
	 (format "211 %d %d %d %s\n"
		 (length articles)
		 (car articles)
		 (car (last articles))
		 group))
	(insert (mapconcat
		 'number-to-string
		 articles
		 "\n"))
	(insert "\n.\n")
	t)
      nil)))

The complicated part is to use this function in the general Gnus back
end. It's pretty scary down there.

-David