bbatsov/emacs-prelude — Issue #10: A suggestion: separate policy from implementation, separate your package from hardcoded values
Author: jerryasher
Created: 2011-10-12 02:15:36+00:00
State: open

I've been using emacs-prelude for much of a day now, and well, I am very impressed. It's a sophisticated package and leaps frog me way beyond the various old versions of emacs to a much more modern emacs, so thank you very much.

If I had a suggestion, it would be that your various prelude modules often mix implementation of some functionality with the hardcoded use of that functionality. So for example, you automatically load the zenburn theme, turn whitespace-mode on, and do similar things in the same files that you are also just setting up various hooks and other modes.

This means that a user who wants to track what you do with emacs-prelude finds it difficult to not load the zenburn theme, or to not use whitespace-mode, or to find other ways to tweak once more what you have tweaked. I don't think that's the way out of .emacs bankruptcy.

Or, as the Emacs Lisp Coding Conventions say, http://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html#Coding-Conventions

```Simply loading a package should not change Emacs's editing behavior. Include a command or commands to enable and disable the feature, or to invoke it.
This convention is mandatory for any file that includes custom definitions. If fixing such a file to follow this convention requires an incompatible change, go ahead and make the incompatible change; don't postpone it.```