From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4456 Path: main.gmane.org!not-for-mail From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) Newsgroups: gmane.emacs.gnus.general Subject: Re: Questions about backend interface and ranges Date: 15 Dec 1995 20:14:50 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Sender: larsi@ifi.uio.no Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145198 29606 80.91.224.250 (20 Oct 2002 20:19:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:19:58 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id LAA02355 for ; Fri, 15 Dec 1995 11:51:25 -0800 Original-Received: from surt.ifi.uio.no (4867@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 20:14:52 +0100 Original-Received: (from larsi@localhost) by surt.ifi.uio.no ; Fri, 15 Dec 1995 20:14:51 +0100 Original-To: ding@ifi.uio.no In-Reply-To: visigoth@olivier.pc.cs.cmu.edu's message of 14 Dec 1995 22:38:57 -0500 Original-Lines: 69 Xref: main.gmane.org gmane.emacs.gnus.general:4456 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4456 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.