What functionality does prelude provide? Unless I'm missing something, the website suggests that you can find out by "reading the source."
I had a similar experience once with the emacs starter kit [1]. Though it's a noble effort and probably does have a ton of great features, there are some problems: you pretty much get all or nothing (ESK split it out into a "core" and "per-language" set of libraries but still, there's a lot of stuff) and it's hard to tell which things are emacs builtin and what is customizable. If you disagree with a customization you're SOL; I knew enough about emacs to know that some things had been customized, and I didn't like them, but it was nigh impossible to find out where they were customized and how to turn them off.
It reminds me of the libraries vs frameworks discussion [2]. Emacs works well with libraries (with little elisp functions counting as "mini-libraries"), and the ESK/prelude seem like frameworks.
I'm not trying to pick on these toolkits in particular. They are probably a good way to start out with emacs--I know that the ESK provides a bunch of features to make it more "friendly" out of the box for someone who is coming from something like TextMate.
Most "old-school" emacs people I know have their own .emacs that have accumulated over years and years of trying to solve specific problems or customize that one thing that's annoyed the crap out of them for a while. My .emacs is not pages and pages, but it does have some good stuff in it.
What I'd love to see (and maybe I'm inviting myself to do this) would be a tool (maybe ELPA is this tool, though It's hard to know) which allows you to search for, browse, and install elisp snippets to help you out. ELPA is good for bigger libraries (i.e. major modes) but not for "how do I create an unfill-paragraph function?"
For what it's worth, I've come around to this viewpoint. I rewrote ESK for version 2, and the emphasis was on packaging as much functionality in independent packages as possible. So as of v2, the Starter Kit is mostly just about providing a default set of packages and turning on a few flags that it's just crazy to leave off (like ido). But this way more of the functionality is available to everyone, not just users of ESK.
Anyway, it certainly needs more documentation, but these days I recommend the Starter Kit more as a source of inspiration than something people should just use outright, at least if they're not in a hurry.
Thank you so much for ESK! It's really helped me get started in emacs. Also, could you think about adding undo-tree as a default for ESK? I really feel like that would be a worthy addition.
Glad you like it. I think rather than further development on the Starter Kit, effort would be better spent towards coming up with a good overview of the ecosystem, documenting available packages and how they work together.
And pushing improvements (like saner defaults, and documentation for some of the under-documented built-in packages) upstream to Emacs itself.
For those reasonably comfortable with Emacs, I think you should build it from source, and get into the habit of fixing tiny documentation problems as soon as you come across them. Mind you, I have submitted a couple such patches to the ido built-in help and they have languished un-noticed for 2 months.
P.S. Another thank-you here for the starter kit -- I no longer use it, but I did for a year or so and it did teach me several features I wouldn't have known about otherwise.
Pushing upstream is absolutely the best way to get things more widely used, but unfortunately changes to the defaults often get strong pushback from long-time users. It's a very politicized process; if improving Emacs itself were easier the Starter Kit never would have existed.
"Short Story: el-get allows you to install and manage elisp code for Emacs. It supports lots of differents types of sources and is able to install them, update them and remove them, but more importantly it will init them for you."
I'm one of the el-get devs. I'd say the main advantage of el-get for the gp is that just installing it doesn't modify your emacs config in any way. In contrast to something like the ESK, it is not an opinionated set of defaults to help new users get started. It is literally nothing but a system for installing and initializing elisp code. Many of the recipes provide some initialization code to set up the code being installed, but you can completely replace that code with your own if you don't like it (or you can decide not to use the provided recipes at all and just write all your own).
It's definitely a more hands-on, low-level tool than ESK, designed for those who want the fine-grained control of a manually-built emacs config without all the manual labor of git-cloning (or hg cloning, or downloading and untarring, or cvs checkout-ing) the several dozen elisp repos that your config uses. It definitely matches my use case, which is why I kept submitting so many pull requests that the original author finally just gave me a commit bit :).
Note that I'm not saying that el-get is in any way better than ESK (I've actually contributed to ESK as well even though I don't personally use it, since ESK uses my ido-ubiquitous library). El-get is just designed for a different purpose.
Ugh. The guy maps a bunch of global keybindings, including hippie-expand and ibuffer, loads a low contrast color scheme as default, but still has the temerity to write:
"I firmly believe that the one true way to use Emacs is by using it the way it was intended to be used [...] That's why I've disabled all movement commands with arrows - to prevent you from being tempted to use them."
I've been wanting to check it out for a while, but I haven't been brave enough to run a non-stable release of GNU Emacs.
http://batsov.com/prelude/