Re: Questions about backend interface and ranges

[larsi@ifi.uio.no (Lars Magne Ingebrigtsen)]

visigoth@olivier.pc.cs.cmu.edu (John McClary Prevost) writes:

> The ARTICLES argument of retrieve-headers is said to take "either a
> range of article numbers or a list of Message-IDs."  I take that to
> mean that it can contain Message-IDs, or a range, but not both?

Yup.  But you should take the "range" thing in the manual with a pinch
of salt.  Gnus uses virtually nothing but sorted numerical lists for
all these functions.  (Sorted numerical lists are a degenerate form of
a range, though, so the manual isn't actually wrong.  It's just more
strict than what the reality is.)

> Second, I'm about to implement a set of "useful range operations" in
> order to get the nnimap stuff working better. 

All the functions you outline are indeed useful.  The reason that
Gnus doesn't use (proper) ranges for much now is that functions like
that hadn't been written yet.

So if you write the functions, Gnus will begin to make them useful.
:-)

> (nnimap-range-split RANGE &optional COUNT)
> 
> This function takes a RANGE and returns a cons cell of a range
> containing the first numerical member of the range and the range
> without that first member.  I.e.:
> 
> (nnimap-range-split ((1 . 5) 7)) => ( (1) . ((2 . 5) 7) )

Perhaps `range-car' and `range-cdr' would be two useful functions
instead?  They would (kinda) mimic what `car' and `cdr' do for normal
lists...

> If the optional COUNT is given, COUNT items are returned as a second
> range.  Like so:
> 
> (nnimap-range-split '((1 . 20) (30 . 500)) 400) =>
>    ( ((1 . 20) (30 . 410)) . (411 . 500) )

That would be extremely useful.  I hadn't thought of that one.

> [ The function might better be split into two: *-range-head and
>   *-range-tail ]

Common Lisp calls the equivalent list functions `but-last' and
`last'...  No, wait, these would return ranges (lists) and `last' jsut
returns the last element...

> (*-range-length RANGE) : returns the number of individual articles in
> a range.

Yup; very useful.

> (*-range-eq RANGE1 RANGE2) : returns t if they're equivalent, nil if
> not.  This is a fairly easy operation, and has O(n+m) where n is the
> number of discrete elements in RANGE1 and m is the number in RANGE2.

Yup.

> I'll code these into my nnimap.el for the time-being, but they'd
> probably be better off in some other piece of code.

I haven't suggested this to RMS yet, but I would like functions like
this to exist in a separate "range.el" package, so the functions would
just be called `range-eq' and stuff.

-- 
Home is where the cat is.