Re: mail-sources backend specific?

["Michael Teichgräber" <mt@wmipf.in-berlin.de>]

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.)


> 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<backend>-* 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), ...

>>>> <alternative approach>
>>> 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. :-(


> 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?