From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/17140 Path: main.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Newsgroups: gmane.emacs.gnus.general Subject: Re: mh backend Date: 15 Sep 1998 17:53:21 -400 Sender: owner-ding@hpc.uh.edu Message-ID: References: <199809152034.QAA20607@math.gatech.edu> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035155895 31838 80.91.224.250 (20 Oct 2002 23:18:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:18:15 +0000 (UTC) Cc: rsi@lucent.com, "(ding)" Return-Path: Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id SAA15451 for ; Tue, 15 Sep 1998 18:18:53 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id QAF00402; Tue, 15 Sep 1998 16:49:45 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 15 Sep 1998 17:17:13 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id RAA12100 for ; Tue, 15 Sep 1998 17:17:02 -0500 (CDT) Original-Received: from pluton.rtsq.qc.ca (pluton.grics.qc.ca [199.84.132.10]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id SAA15411 for ; Tue, 15 Sep 1998 18:16:55 -0400 (EDT) Original-Received: by pluton.rtsq.qc.ca (8.8.8/8.8.8) with UUCP id RAA27040; Tue, 15 Sep 1998 17:54:27 -0400 Original-Received: by icule.progiciels-bpi.ca (8.8.5/8.7.3) id RAA15967; Tue, 15 Sep 1998 17:53:22 -0400 Original-To: Richard Coleman X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m > > 1. Message sequences. > > What are they? > In MH/nmh, you can give symbolic names to an arbitrary list of > numbers. Then you can manipulate the messages that these numbers > represent, by using the message sequence. [...] > In MH, I can assign a compound sequence of messages a name and can > limit my operations to operate on specific sequences. [...] Could mailgroups, or submailgroups, be used to similar purposes? Maybe not, if a single message may be part of many sequences simultaneously. Let's assume for a moment it would be possible... > All the MH/nmh will take message sequences as arguments. Also, there are > commands for adding or deleting messages from a sequence. This makes it > very easy to remove, refile, search, or forward a collection of messages. A bit like it would be easy to handle messages in mailgroups. `M P a' could select all messages from a group, if I remember correctly. > It's a very powerful tool. I've always wondered why other mail > readers haven't done similar things. Sometimes, there are other but different paradigms which have similar powerfulness? It's always a bit difficult to compare different approaches. Maybe you could define something that fits well in the various Gnus paradigms, and that would give you the functionality you need? > Well, it's common to repack the folder in the MH/nmh world. The message > numbers are not hidden in the background quite as much as in Gnus. Maybe (just hypothesising :-) because you often need to look at these numbers. If you stopped having this need, probably the need to repack would disappear as well? > Yes, limiting takes care of matching on headers, but unless I'm > missing something obvious, one cannot limit based on the contents > message body. For one, I do it with temporary scoring instead. Maybe it would be convenient that have a limiting function for that as well? It might be slow. > I find this occasionally useful when searching for a particular piece > of email. People speak highly of `nnir', maybe it could help? Maybe it is overkill? > If I expire them, it leaves a gap in the message numbers and then the > count of messages is inaccurate since Gnus calculates the number of > articles based on the article numbers of the first and the last articles. Maybe the good approach would to have Gnus count correctly, then? Repacking numbers looks a fairly heavy operation, around a Gnus limitation which might be lifted, presumably. > I do think that I shall look into adapting and implementing some of > the nifty MH features that I've been silently missing for so long. :-) Good for us! :-) -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard