Re: mail-sources backend specific?

[kai.grossjohann@gmx.net (Kai Großjohann)]

Michael Teichgräber <mt@wmipf.in-berlin.de> 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<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), ...

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?

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

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)