From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52221 Path: main.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: mail-sources backend specific? Date: Sun, 04 May 2003 15:29:59 +0200 Organization: University of Duisburg, Germany Sender: ding-owner@lists.math.uh.edu Message-ID: <84el3eet60.fsf@lucy.is.informatik.uni-duisburg.de> References: <84u1cknes9.fsf@lucy.is.informatik.uni-duisburg.de> <87fznxzemr.fsf@wmipf.in-berlin.de> <84d6j1bhn3.fsf@lucy.is.informatik.uni-duisburg.de> <87el3hxw5b.fsf@wmipf.in-berlin.de> <84isstiewq.fsf@lucy.is.informatik.uni-duisburg.de> <87he8d752z.fsf@wmipf.in-berlin.de> <87he8cav01.fsf@wmipf.in-berlin.de> <8465ost014.fsf@lucy.is.informatik.uni-duisburg.de> <87znm3g5qz.fsf@wmipf.in-berlin.de> <847k97zr1k.fsf@lucy.is.informatik.uni-duisburg.de> <87r87fph6s.fsf@wmipf.in-berlin.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1052055094 5226 80.91.224.249 (4 May 2003 13:31:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 4 May 2003 13:31:34 +0000 (UTC) Original-X-From: ding-owner+M764@lists.math.uh.edu Sun May 04 15:31:32 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19CJaW-0001M7-00 for ; Sun, 04 May 2003 15:31:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19CJbf-0005Yi-00; Sun, 04 May 2003 08:32:43 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19CJbb-0005Yd-00 for ding@lists.math.uh.edu; Sun, 04 May 2003 08:32:39 -0500 Original-Received: (qmail 52542 invoked by alias); 4 May 2003 13:32:38 -0000 Original-Received: (qmail 52537 invoked from network); 4 May 2003 13:32:38 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by sclp3.sclp.com with SMTP; 4 May 2003 13:32:38 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 19CJcp-0003zz-00 for ; Sun, 04 May 2003 15:33:55 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 131 Original-NNTP-Posting-Host: p5087707f.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1052055235 15021 80.135.112.127 (4 May 2003 13:33:55 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 4 May 2003 13:33:55 GMT Mail-Copies-To: never User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:AuYV4XoYq16k1eVBx7WUHCdllN4= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52221 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52221 Michael Teichgräber writes: > kai.grossjohann@gmx.net (Kai Großjohann) writes: > >> But what happens if you have two nnml backends and in both you set a >> variable (a parameter?) nnml-foo? Then the first can influence the >> second in the same way, no? > > In such a case you would choose a different server name (instead of > "") for the second backend, wouldn't you? So there wouldn't be a > problem. > > (If you use the Agent, you already are using multiple nnml backends.) You were giving an example with nnfolder and nnml. And you set that nnoo sets the variables globally. So if the nnfolder server sets variable mail-sources, and nnml sets the same variable, then the two settings will step on each other's toes, because the name is the same. Now if you have two nnml servers and both servers set nnml-mail-sources, then you have the same stepping-on-toes problem. But this is just my understanding of what you said previously, and I think that understanding is way off. I'll read your original message again. >> Is there a more serious bug here? > > No, it works very well. ;-) > > From what I have learned so far, each backend has a current > server. There are global variables nn-* that represent the > settings of this current server. These variables coexist with nn*-* > variables of other backends without problems because of different > "nn*-" prefixes. > > If the server changes for a certain backend foo from current server > bar to new server baz (e.g. to read mail from baz now), > nnoo-push-server stores all global variables nnfoo-* (that have an > entry in nnoo-definition-alist) into the sub-list within > nnoo-state-alist that corresponds to bar. Then the values of server > baz are extracted from nnoo-state-alist and stored into the global > variables nnfoo-*. > > Since global variables of current backend-server pairs must > coexist (they do if being prefixed properly), ... Hm. So does this mean that nnoo treats nnchoke-foo variables differently from frumple-foo variables, because nnchoke is the name of the backend and frumple isn't? >>>>> >>>> But OTOH, server variables may be useful for other things, so what do >>>> you think about fixing the server variable handling? >>> >>> [...] >> >> What I meant is to make > >> (setq gnus-secondary-select-methods >> '((nnfolder "" (mail-sources foo)) >> (nnml "" (mail-sources bar)))) >> >> behave as you (and I) desire: fetch mail from foo for the nnfolder >> backend and from bar for the nnml backend. > > ... ^^^ this will be difficult to achieve, as there cannot be > different "mail-sources" variables in the same (global) namespace. :-( Okay. Well. Hm. Err. Suppose you have this situation: (setq gnus-secondary-select-methods '((nnml "one" (nnml-mail-sources foo)) (nnml "two" (nnml-mail-sources bar)))) Clearly there must be a mechanism that prevents the two settings for nnml-mail-sources stomping on each other. So can't this mechanism be used to also protect mail-sources, instead of only nnml-mail-sources? >> Maybe it's enough to make the variables local to the current buffer? >> But probably it isn't -- Gnus jumps around the buffers a lot. > > Even if servers were changed only in the Group buffer, there still > would be the problem of variables of current backend-server pairs > having to coexist. > > > But, nnoo-change-server could be extended to automagically > provide proper prefixes for variable names that do not start with > "nn[^-]+-". A "mail-sources" would then be translated to > "nnfolder-mail-sources" for backend "nnfolder". This would allow the > init file to look like > > ------------------------------------------------------------>8---------- > (setq gnus-secondary-select-methods > '((nnfolder "" > (mail-sources ((file :plugged t) > (directory :path "~/Mail/incoming-nnfolder" > :suffix "" > :plugged t))) > (directory "~/Mail/nnfolder") > (active-file "~/Mail/nnfolder/active") > (get-new-mail t)) > > (nnml "" > (mail-sources ((directory :path "~/Mail/incoming-nnml" > :suffix "" > :plugged t))) > (directory "~/Mail/nnml") > (active-file "~/Mail/nnml/active") > (get-new-mail t))))) > ----------8<------------------------------------------------------------ > > The same for gnus-message-archive-method. If have tested this with a > patch to nnoo.el, and it seems to work (it's practically the same as > specifying nnfolder- resp. nnml-). > > Opinions? That's a cool trick. But it still requires variables nnchoke-mail-sources. So your previous patch of frobbing nnchoke-get-new-mail is still necessary, I believe. Not sure if that helps at all. -- file-error; Data: (Opening input file no such file or directory ~/.signature)