Most of the time, things appear to work because everyone writes their font-lock modes in terms of meaningful colors, like "font-lock-builtin-face", but as soon as you venture outside of what font-lock provides, you're fucked if the color theme author doesn't use the modes you do. And since pretty much everyone uses different modes, color themes simply do not work. (I usually define my colors in terms of the font-lock faces to make sure that color themes work. But sometimes you have more information than a normal font-lock mode does, and then you have to manually select a new color. Hashes and arrays in cperl-mode are a specific example.)

I also have some specific complaints about how the mode is written. Why is the color theme definer burdened with quasiquoting and color classes when a macro could make it possible to sanely extend the color theme without extra work? Something like:

   (define-color-theme solarized
      :base-colors-for light
          foo "#abcdef"
          bar "#fedcba"
          baz "#coffee"
      :mode-colors-for light
          background foo
          font-lock-builtin-face bar
          ...) 

Also, while I'm whining, why do people name their own fucked-up Emacs config things like "Emacs Prelude" instead of "my .emacs"? I agree that many of Emacs' defaults are stupid, but the solution is education, not a random .emacs that invalidates the Emacs documentation. When you change all the defaults, you'd better provide a new user manual, or people are just going to be confused.

Sorry if this sounds harsh, but I got my wisdom teeth out yesterday and the painkillers are not doing much for me. :)

1: "Hey try this configuration until you're up to writing your own."

2: "Which one?"

1: "my .emacs"

Rather than being able to Google: "Emacs Prelude" or "Emacs Starter Kit".

As for educating new users, most people simply don't have the time or regard to build an Emacs configuration that they can be productive with right away from day 1. There's just too much to know all at once. Emacs configurations such as the Emacs Starter Kit and Prelude provide a centralized place for new users to learn. I see how configurations can do anything to increase the confusion they already have. They either don't care and just like how it works better than without the configuration, or they're interested and use THE manual by doing the C-h's, or browsing the configurations files learning new things incrementally, when they feel like it.

Ultimately, life-long Emacs users have their own set of defaults that they have learned to like over the years. This is due to muscle memory and habit rather than any objective good. I recently killed two thirds of my own .emacs and it removed many long-standing annoyances. Emacs improves, hacks on top of hacks called config files don't.

If all sets of possible configurations are equally bad, why not stick to the config file that doesn't require an actual file, and then let users M-x customize as appropriate? You may not like customize, but it's pretty nice for people that are new to Emacs. (And, actually, I try to do everything via customize because I'd rather let the computer maintain my config file.)

That's why they threw out color-theme.el and reimplemented it from scratch in Emacs 24.

A good example of the color proliferation problem is egg; it defines its own diff-added and diff-removed colors, which means if you've already fixed the colors for diff-mode, you have to do the same fix again for egg.

So while, yes, color-theme didn't actually work as documented and the new stuff does, it's still practically impossible to try out various color themes.

According to your CV on Github, you're a few months older than me. I started using Emacs in 1999 on my Rev. B iMac running MkLinux. I also have code in the Emacs core, maintain cperl-mode, and wrote eproject (which seems to be pretty popular these days). I've also taught Emacs to high school students. So it is quite possible that I know what I'm talking about.

Such configs are designed to spare them the effort it took people like to me to develop them and achieve good productivity.

They may be designed to do that, but how are you sure your design works? Do you A/B test? Do you have any data?

My philosophy differs from yours. It posits that people will not learn things though being forced to do something; people will only learn if they have internal motivation and easy access to facts. The real world is not a bunch of cookie-cutter problems that can be solved by applying a set of rules. The real world is too complicated for this, and in order to be able to navigate in the real world, you have to build skill and intuition. You do this by practicing with an eye towards improvement. If you don't have intuition, you are just a wet bag of protein, fat, and water acting like a very shitty computer. And no set of configuration files is going to give someone intuition.

Let's talk about disabling the arrow keys. I get why you want to do that. The arrow keys are far from home row, and the context switch takes a long time, and that distracts you from what you really want to do: your work. If you tell someone that they might believe you, but they won't really believe you until they try both ways and decide which is better for them. It might be that the habit of pressing the arrow keys is impossible for them to break, and using the Emacs navigation keys will never work for them. By not giving them the choice, they won't ever be able to use Emacs at all, and that's worse than using it wrong until they decide they want to try to improve a bad habit.

Learning is a feedback loop, and if all you get is negative feedback, you won't learn. By starting at the "end" (your "ideal configuration"), the user misses all the learning that he would have experienced by starting from the beginning and working through until the end. He needs positive feedback to get started, and that means using the arrow keys until they actually become a bottleneck for him. In the mean time, his brain can be put to better use; learning his programming language, learning about incremental searches, learning about the kill ring. Eventually, all those things will be so second-nature (through focused practice) that he'll be looking for new ways to make himself even more productive. At that point, it becomes worthwhile to try and break the arrow keys habit. But before that point, it's not worthwhile.

With a one-size-fits-all configuration, you teach people that Emacs is brittle and that they are dumb. And that's the opposite of reality; Emacs is flexible and the user is smart!

https://github.com/bbatsov/zenburn-emacs