Re: mail-sources backend specific?

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

kai.grossjohann@gmx.net (Kai Großjohann) writes:

>> This is not what has been expected.
>
> What was expected?

s/expected/desired/

It worked as it was told, but it did not result in the behaviour I
wanted: retrieving local mail for more than one backend.

And, the "mail-sources" entries, that had been inserted into
nnoo-definition-alist, looked strange. This was because the
"mail-sources" parameter of the select-method (obviously) didn't have
a nnfolder- or nnml- prefix (as for other server variables). So the
first call of nnoo-change-server (for backend nnml) could influence
the later call (for backend nnfolder) by means of the current
global "mail-sources" value.


>> <alternative approach>
>>
>> Would it break the design, if mail-sources was handled as server
>> variable too, so that -- depending on backend -- "nn*-mail-sources"
>> could be specified?
>
> That sounds like a plan.  For completeness, some defvoos might have
> to be added, but it looks quite nice.

E.g. (defvoo nn*-mail-sources nil) for all backends that retrieve
mail: nnmh, nnml, nnfolder, nnimap ...


> But OTOH, server variables may be useful for other things, so what do
> you think about fixing the server variable handling?

With 'fixing' do you mean making it work with variable-value pairs as
desired some mails before? -- Such as

    (setq gnus-secondary-select-methods 
	  '((nnfolder "" (A X)))
	    (nnml "" (A Y))) ,

so that A (not having nnfolder-, nnml- prefixes) may have different
values in contexts of these backends? Or did you refer to my "is not
what has been expected"?