From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48522
Path: main.gmane.org!not-for-mail
From: Lloyd Zusman <ljz@asfast.com>
Newsgroups: gmane.emacs.gnus.general
Subject: Concerning marks and the back end.
Date: Wed, 01 Jan 2003 17:23:17 -0500
Organization: FreeBSD/Linux Hippopotamus Preserve
Sender: owner-ding@hpc.uh.edu
Message-ID: <86fzsc4ii2.fsf@asfast.com>
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1041459794 20112 80.91.224.249 (1 Jan 2003 22:23:14 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Wed, 1 Jan 2003 22:23:14 +0000 (UTC)
Return-path: <owner-ding@hpc.uh.edu>
Original-Received: from malifon.math.uh.edu ([129.7.128.13])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 18TrGa-0005E4-00
	for <ding-account@gmane.org>; Wed, 01 Jan 2003 23:23:12 +0100
Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists)
	by malifon.math.uh.edu with esmtp (Exim 3.20 #1)
	id 18TrGw-0000yR-00; Wed, 01 Jan 2003 16:23:34 -0600
Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 01 Jan 2003 16:24:29 -0600 (CST)
Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2])
	by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id QAA21158
	for <ding@hpc.uh.edu>; Wed, 1 Jan 2003 16:24:17 -0600 (CST)
Original-Received: (qmail 53709 invoked by alias); 1 Jan 2003 22:23:19 -0000
Original-Received: (qmail 53704 invoked from network); 1 Jan 2003 22:23:19 -0000
Original-Received: from home.acholado.net (HELO home) (Potamus@216.27.138.216)
  by 66.230.238.6 with SMTP; 1 Jan 2003 22:23:19 -0000
Original-Received: from localhost (localhost [127.0.0.1])
  (uid 1001)
  by home with local; Wed, 01 Jan 2003 17:23:18 -0500
Original-To: ding@gnus.org
X-Face: "!ga1s|?LNLE3MeeeEYs(%LIl9q[xV9!<nimJxd1qyQRquvu5XTnZ:_5VE-G&4*EAuW"7oJLIXj'DWrJ0z@,FlwvD2PA@qhQ2R#zgsc14Klk;OSE'*;+l8p?0^nK7*X#0zg5wd^!M^2pg,M4Qd^{1viG;fa{}b.s[?g(x$45c]]=@'ZQ&]sPXl!u:hxBAv>j4#xf4!**BFW_ihlOb;:Slb>)vy>CJM<qjGM,/6C6\|{))YWm6}Q#?3om%n8
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp,
 i386-debian-linux)
Precedence: list
X-Majordomo: 1.94.jlt7
Xref: main.gmane.org gmane.emacs.gnus.general:48522
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48522

Since gnus is making use of `.marks' files these days, I'm wondering if
there's a way to solve the following problem that I'm having:

In some groups, I keep a large history of old messages.  Therefore, it
can be very slow to enter such a group.  If I want to speed things up,
one thing that I know I could do would be to create some sort of
auxiliary group for each of these groups, wherein I can put most of the
old articles.  This way, under normal, everyday use, I can enter the
main group relatively quickly, and those more infrequent times when I
want to look through the old articles, I can go to the auxiliary group.

But I'm wondering if I can avoid these auxiliary groups.  I'm wondering
if there's a mark or set of marks that I can put on articles, and whose
existence would be noted in the .marks file for any given group.  And if
so, would it be possible to set up a group so that under normal group
entry, any article ranges that are marked with this special mark will
cause the articles to be ignored with no query being done to the back
end? ... and only if I enter a group in a non-standard way (i.e., via
a different command or a special prefix argument) would these special
marks be ignored and the entire list of articles would be quieried
from the back end.

This way, I could keep all articles in their original group, with the
oldest articles marked in this special way.  Entering the group in the
"normal" manner would be fast, since no back-end query would need to be
done for any articles for which the .marks file indicates the existence
of this special mark.  These back-end queries would only be performed
for the non-marked (in this case, newest) articles.

I hope I explained this clearly.

Is this something that can now be done in some way, or which perhaps
could be added without a huge amount of complexity?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com