Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

"William G. Gardella" <wgg2@member.fsf.org> writes:

> Ugh, I mean (mapcar 'disable-theme
> custom-enabled-themes)

Aha, so that word ("theme") is already in Emacs!
Deeming from the help, a theme is a variable and face
settings state.

I guess "variable" means keymaps as well?

Including keys in the word "theme" is stretching it a
bit, because I take it the themes will be named like
the Openbox themes (like "day", "fog-mine", etc.),
i.e., based on what they look like, and not on finger
habits. I configured the Dired keys and the Gnus keys
to coincide, so I guess that's a "theme" as well, and
I'll call it "ijkl"... But this example shows that it
is just not an intuitive use of the word. I mean, how
many other such "themes" can you think of?

Is there a need for *one* word for this? To me,
intuitively:

1. If you disable the scrollbar or set the foreground
   face, that's customize.
2. If you rebind the keymaps and change the parameters for
   scrolling, filling, etc., that is configuration.
3. If you write wrapper functions and aliases, that is
   tuning and streamlining the interface
   (personalization, perhaps).
4. If you write Elisp that does something that's not in
   Emacs at all, that extension.

For it to be a "theme", the changes must hook into each
other in a way that emphasizes some common factor. For
1, you can have a bright-on-black theme, a non-GUI
theme, a minimalist theme, and so on. But for 2-4 I can
only describe my thought how I think it should be, and
nothing more, so either I'm narrow-minded or the
concept theme just does not apply beyond the
superficial level.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573