It is no good to update `org-agenda-files' when setting those variables, only to
be overwritten by customize itself latter on. Maybe it's better to instead have
a custom setter that updates the variable, but also checks whether the file is
also contained in `org-agenda-files', warning the user if this is not the case?
Up to now, it seemed to be sufficient to set `send-mail-function' alone, but
somehow some changes have made it necessary to set `message-send-mail-function'
explicitly. If not done, it defaults to `message-send-mail-with-sendmail',
using the sendmail exectuable to send mail. At least on my machine this results
in the message being delivered to the local exim instance, which does not allow
sending remote sending of mail.
If this is necessary, clock in separately using the interruption template.
However, I have felt that this is rarely useful, to the extend that I haven't
used the note capture template just because it disturbs the clock.
Loading customizations in `db/run-init' may cause accidental overwrites of
custom settings when loading variables changes and saves values of other
customizable variables. For example, loading `custom-enabled-themes' may update
`custom-safe-themes', and if this loading happens after initialization time,
this update is directly written to custom.el via a call to
`customize-push-and-save', overwriting all remaining, i.e. not loaded, custom
settings. Loading custom settings during initialzation time prevents this
behavior.
Note that this change causes some packages to load during initialization time
that previously had been loaded only afterwards.
This allows to specify files to be loaded as the last step in `db/run-init'.
This way, custom code can be added to this Emacs configuration without
explicitly adding it to its configuration, making future merges easier.