To help structure the tangled mess that the DotEmacs file can become, the following technique can be used. This technique is based around keeping a list of variable which corresponds to particular features, additional modes or customisations, with a corresponding when clause to wrap the code related to that specific feature.
for example, something like the following at the beginning of the file.
(defvar *slime-enabled* t) ;; superior lisp interaction mode (defvar *globrep-enabled* nil) ;; global find and replace (defvar *dict-enabled* nil) ;; mizspellnigs & dictionaries (defvar *vc-darcs-enabled* nil) ;; darcs using vc interface (defvar *paredit-enabled* nil) ;; paredit-mode
then somewhere further down…
(when *paredit-enabled*
(autoload 'enable-paredit-mode "paredit"
"Turns on pseudo-structural editing of Lisp code." t)
(add-hook 'lisp-mode-hook 'enable-paredit-mode)
(add-hook 'scheme-mode-hook 'enable-paredit-mode))
so setting *paredit-enabled* to either t or nil would enable or disable the feature completely. This can be especially useful when testing several modes for interoperability, or moving to a new setup.
See also DotEmacsRestructuring and DotEmacsModular