From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52206 Path: main.gmane.org!not-for-mail From: =?iso-8859-1?q?Michael_Teichgr=E4ber?= Newsgroups: gmane.emacs.gnus.general Subject: Re: mail-sources backend specific? Date: Sun, 04 May 2003 04:40:59 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: <87r87fph6s.fsf@wmipf.in-berlin.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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1052016376 5141 80.91.224.249 (4 May 2003 02:46:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 4 May 2003 02:46:16 +0000 (UTC) Original-X-From: ding-owner+M750@lists.math.uh.edu Sun May 04 04:46:14 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 19C9Vo-0001KT-00 for ; Sun, 04 May 2003 04:46:00 +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 19C9Wz-0001ju-00; Sat, 03 May 2003 21:47:13 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19C9Wu-0001jC-00 for ding@lists.math.uh.edu; Sat, 03 May 2003 21:47:08 -0500 Original-Received: (qmail 29344 invoked by alias); 4 May 2003 02:47:08 -0000 Original-Received: (qmail 29339 invoked from network); 4 May 2003 02:47:07 -0000 Original-Received: from mail.s.netic.de (212.9.160.11) by sclp3.sclp.com with SMTP; 4 May 2003 02:47:07 -0000 Original-Received: from host-212-9-162-198.dial.netic.de ([212.9.162.198] helo=iridium.renata.de) by mail.s.netic.de with esmtp (Exim 4.10) id 19C9Wr-000FzJ-00 for ding@gnus.org; Sun, 04 May 2003 04:47:05 +0200 Original-Received: from micha by iridium.renata.de with local (MasqMail 0.1.16) id 19C9TK-3qy-00 for ding@gnus.org; Sun, 04 May 2003 04:43:26 +0200 Mail-Reply-To: =?iso-8859-1?q?Michael_Teichgr=E4ber?= Original-To: ding@gnus.org X-Wo-Ist-Die-ISS: http://wmipf.in-berlin.de/sat/curpos.html X-Betriebssystem: Debian GNU/Linux X-Request-PGP: http://wmipf.in-berlin.de/mtgpg.asc X-PGP-Key: 5656 F203 8343 0A2E 8259 6102 3F0D B4F4 1182 8000 User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52206 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52206 kai.grossjohann@gmx.net (Kai Gro=DFjohann) 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.) > Is there a more serious bug here? No, it works very well. ;-) =46rom 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), ... >>>> >>> 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=20 > (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. :-( > 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?