This reverts commit 941c4771ca.
To support backwards compatibility, I need to leave this field/option
in the module, even if it will likely be more confusing to do it this way.
This was originally placed here, seemingly, just to get this module
working. However, this field is actually more confusing now that a
separate per-channel configuration option for extra configurations has
been made available.
These are options that can be handled by the `genSection` function in
the `genAccountFunction`, so they are left to the user to decide.
Most of these are made on a global basis anyways.
Gave the
`accounts.email.accounts.<name>.mbsync.groups.<gname>.channel.<cname>`
set a `patterns` option, which will allow for greater customization
and filtering of the master maildir to sync to the slave maildir.
This is the same method as is used in creating an email account, named
`<name>` under `accounts.email.accounts.<name>`. This allows the user
to specify groups and channels, in a list-like format, but still gets
the "namespacing" to more easily handle the options available in each
of these locations.
This is the end of the configuration that the end-user will use.
They will specify an attribute set that contains the name for the
group, so they can say
`accounts.email.accounts.<aname>.groups.<gname>` to access the
configuration for the group with the name `<gname>`.
A group is a grouping of channels together, so that many channels with
very different names can be handled as a single entity.
Groups are unique in mbsync because they will shadow channels that
have the same name on the command-line.
A channel is a relationship between 2 directories/boxes/mailboxes
between the local machine (slave) and the remote mail server (master).
Each channel must be given at least:
* an account-unique name
* a pattern for which mailboxes to sync from master
* a pattern for what directory where that mail ends up on the
slave
Additional options can be added later.
To allow supporting more advanced configurations. The local refers to
the "maildir store" configuration, remote to the "IMAP store", and
"channel" to the channel.
This reworks the way program specific email account options are
specified. In particular, we no longer use the deprecated `options`
field of `mkOption`. Instead submodules are used.