= Why "Flavors"? =

I'm trying to understand how large, fairly cohesive user-customizations via .emacs.d can be standardized as "flavors".   The point would be to:
* Facilitate both the creation and maintenance of such large scale customizations
* Make it easier for users to install and switch between them
* Extract commonality into libraries

'''NOTE:''' Most long-time Emacs users are expected to not care very much about this kind of effort. 

== Status Quo ==

As far as I can tell, the myriad emacs.d's out there define and follow a variety of patterns.  These days, there's certainly a lot functionality being pulled into libraries.  Dealing with the "end user" customization in concert with such efforts seem poorly defined at the moment.  Customize has been around for a long time and appears to not (by itself) be sufficient for what (and how) people want to customize.  That said, "Custom Themes" may be sufficient.

I've found a few efforts for structuring init files:

* DotEmacsModular - put things into separate files, load them recursively
* DotEmacsStructuring - use "feature switches" to selectively turn stuff on/off
* CategoryCustomize - pointers to particular areas of customization/"flavorfication"
* CustomizingBoth - some ideas and advice on "portability" of such configuration
** Also see CustomizeByPlatform
* EmacsImplementations - different implementations are definitely different flavors, but let's consider them out of scope (for the moment)
* CustomFile - allows you to separate the output of "customize"
* [https://github.com/emacsattic/bind-key bind-key] - for managing personal keybindings
* InitSplit - appears to be in the spirit of CustomFile, but finer grained
* [https://github.com/laynor/smotitah smotitah] - Another configuration framework for emacs
* [[CustomizingAndSaving#CustomizePlus|CustomizePlus]] - helps manage state around customize
* [http://www.gnuvola.org/software/personal-elisp/ personal-elisp] - maybe very applicable, investigating
* [http://tychoish.com/documentation/managing-emacs-configuraiton-and-lisp-systems/ tychoish's approach] - a documented approach

== Possible "Flavors" ==

; flavor : A customization of an Emacs implementation significant enough to warrant its own documentation.

* [[Prelude]]
* [http://github.com/technomancy/emacs-starter-kit Emacs Start Kit (ESK)]
* [https://github.com/rdallasgray/graphene Graphene]
* Some more on [http://ergoemacs.org/misc/list_of_emacs_starter_kits.html Xah's site]
* ...

=== Custom Themes ===

Can "Custom Themes" meet the needs of "flavors" mentioned above?
* They are not mutually exclusive
* Not allowed to set "custom-enable-themes"
* Has some compositional features
* Defines a (top-level?) theme, "user"
* Arbitrary forms are discouraged (elisp) 14.6 Custom Themes
:[quote]In theory, a theme file can also contain other Lisp forms, which
would be evaluated when loading the theme, but that is "bad form".[/quote]

Right now, I think the things I'm referring to as "flavors" need to be mutually exclusive; they're going to define conflicting keybindings and different behavior for the same things and thus cannot be expected to work if layered on top of one another.  That said, perhaps "flavors" is not such a good term because it doesn't denote mutual exclusion.

I think I now prefer the term "suit", as in one wears only one '''EmacsSuit''' that you can have tailored over time. More importantly, it'll have a nice logo.

Further, it may be that custom themes can still be used as part of "suits"; themes are supposed to compose and thus could be the unit of functionality that suits can share between themselves.  As long as suits separate the (possibly) "colliding" portion from the composable theme-stuff, I think we can build on prior work and go forward.  From a package perspective, both "themes" and "suits" would be separate, but suits would depend on themes, not vice versa. 

== Next Steps ==

* Do people think this would be useful?
* Is "flavor" a reasonable term for these things?
* If Customize is good enough, how can we make it more obvious how to package and share a set of customizations?
* Have I overlooked any relevant efforts?

=== Ideas for Formalization ===

* Continue using packages (esk, ergoemacs, and graphene all have packages)
* Provide a "switching" function (probably too difficult to get 100% right)
* Where applicable, define common:
** file system layout
** function/var/package naming schemes
* Help/Documentation conventions, e.g. overview of novel keybindings, changes to default behavior

= See Also =

* [[Suits]] - the next iteration emphasizing mutual exclusivity, use of custom themes
* [http://tychoish.com/rhizome/make-emacs-better/ tycho's thoughts], plus [http://tychoish.com/rhizome/make-emacs-better/discourse/ some discussion], on new user adoption (don't agree about needing more than elisp, save maybe FFI for C)