From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/34951 Path: main.gmane.org!not-for-mail From: ShengHuo ZHU Newsgroups: gmane.emacs.gnus.general Subject: Re: regexp-based group parameters Date: 23 Feb 2001 18:22:44 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <2n66i1j86z.fsf@tiger.jia.vnet> References: <873dfg9z1x.fsf@splinter.inka.de> <87wvcs8awc.fsf@splinter.inka.de> <878zp71ef0.fsf@lovi.inf.elte.hu> <2nelwpja7z.fsf@tiger.jia.vnet> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035170778 468 80.91.224.250 (21 Oct 2002 03:26:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:26:18 +0000 (UTC) Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id DBEA6D049F for ; Fri, 23 Feb 2001 18:22:42 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id RAB24475; Fri, 23 Feb 2001 17:22:35 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 23 Feb 2001 17:21:50 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id RAA14556 for ; Fri, 23 Feb 2001 17:21:38 -0600 (CST) Original-Received: from zsh.yi.org (roc-24-93-30-91.rochester.rr.com [24.93.30.91]) by mailhost.sclp.com (Postfix) with ESMTP id 11EA9D049F for ; Fri, 23 Feb 2001 18:22:08 -0500 (EST) Original-Received: (from zsh@localhost) by zsh.yi.org (8.11.0/8.10.0) id f1NNMid23104; Fri, 23 Feb 2001 18:22:44 -0500 Original-To: ding@gnus.org X-Attribution: ZSH X-Face: 'IF:e51ib'Qbl^(}l^&4-J`'P!@[4~O|&k#:@Gld#b/]oMq&`&FVY._3+b`mzp~Jeve~/#/ ERD!OTe<86UhyN=l`mrPY)M7_}`Ktt\K+58Z!hu7>qU,i.N7TotU[FYE(f1;}`g2xj!u*l`^&=Q!g{ *q|ddto|nkt"$r,K$[)"|6,elPH= GJ6Q In-Reply-To: (prj@po.cwru.edu's message of "23 Feb 2001 17:55:27 -0500") User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.99 Precedence: list X-Majordomo: 1.94.jlt7 Original-Lines: 58 Xref: main.gmane.org gmane.emacs.gnus.general:34951 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:34951 prj@po.cwru.edu (Paul Jarc) writes: > ShengHuo ZHU writes: > > prj@po.cwru.edu (Paul Jarc) writes: > > > > * Group/topic parameters allow setting arbitrary variables, not only > > > > `strict' parameters. > > > > > > I'm not sure this is a problem. Your gnus-parameters doesn't seem to > > > address it, either. > > > > As to group variables, it is. > > How so? NAGY Andras means that regexp scheme was not able to configure group variables. In this sense, gnus-parameters can do this. > > > I'd like it if parameters were (or could be) stored in backends. > > > Backends can already use -request-update-info to correct Gnus's > > > parameters, so we just need a way for Gnus to notify the backend when > > > the user modifies the parameters. (Then once all backends do this, > > > Gnus could stop redundantly storing parameters in newsrc.eld.) > > > > Using -request-update-info is another issue. > > What do you mean? Unfortunately, we can not implement this for some backends without some extra helps (e.g. local files). It could also be a problem for shared or readonly groups. > > > Also, to provide for hierarchical inheritance, we could have a > > > parameter called, say, parameter-parent, whose value is a group. [...] > > > > I don't like this idea. Regexp scheme is much clearer and easier to > > maintain. > > But it also means that I can't deal with group names and parameters as > the separate entities they are. If I want two groups to share a set > of parameters, I'm *forced* to either name them similarly, or else use > an ugly, *less* maintainable regexp to identify them. You don't have to. mapconcat and regexp-quote are your friends. > > > Your suggestion (like mine) fails to cover the capability we have now > > > of putting a group into multiple topics, and using the parameters of > > > whichever topic the user entered through, but this seems like more > > > trouble than it's worth, especially in situations where there is no > > > "current" topic. > > > > This is the weakness of topics implementation. > > Right. But parameter-parents would be an *ordered* list of parents, > and unrelated to topics, so there'd be no ambiguity. It is difficult to avoid loop links in your parameter-parents scheme. ShengHuo