Flavors

Last major edit (later minor edits)

Summary: add smotitah config framework

Added:

> 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.


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:

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:

Possible "Flavors"

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

Custom Themes

Can “Custom Themes” meet the needs of “flavors” mentioned above?

In theory, a theme file can also contain other Lisp forms, which would be evaluated when loading the theme, but that is “bad form”.

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

Ideas for Formalization

See Also