Re: Pushing the `gnus-range-*' functions down into the C layer

[Daniel Pittman <daniel@rimspace.net>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

[...]

>> What algorithms do you use there?  These should be O(n), right?  What do
>> you know about the usual shape of your data?  E.g. what's the expected
>> difference between the smallest and the largest element (if it's not too
>> large, we could store them in bitvectors and then provide bitwise or/and on
>> bitvectors)?
>
> It varies a bit.  The "read" range is usually on the form `(1 . 24254214)',
> and this is (of course) never uncompressed.  But you'd usually have
> additional ranges for, say, ticked, and these would be quite sparse, like
> `(45 (90 . 96) (200 . 259))' Or something like that.

Oh, wouldn't it be lovely if there were all so polite.  One of the problems my
IMAP server delivers is that I get this data for long-lived folders with
sparse email as is available here — because it is 8K in size.

    http://daniel.rimspace.net/gnus.el

This is the nice version, incidentally, where I use a copy of the source into
Dovecot because it returns a nicer set of UID values.  The original spaces,
for me, many email UIDs by ~ 100, ensuring that there are *no* contiguous
numbers available in the sparse set that Gnus is working with.

(It also leads to mailboxes with ~ 1000 numbered items across a range from 1
 through 750,000 or so.)

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons