On Thu, 03 Jan 2008 04:50:57 -0500 Richard Stallman wrote: > I have found the Emacs community to be one of the most responsive > and skill= ed=20 > group of developers in open-source, > > Please do not use the term "open source" to describe what Emacs is in. > Emacs is part of the GNU Project, which is part of the free software > movement. To call us "open source" is like callingt Kucinich a > Republican. > > , but trying to straddle all the schisms = > to=20 > support users is really hard. > > We sometimes adopt features to make it easier for code > to run in the variants of Emacs. But I don't really understand > what you mean by "split the setup" here, I think I can articulate this a bit better now. My interest in this thread revolved around the idea of a more advanced Emacs user being able to help a newer user setup a Emacs environment that is appealing with more features than the default configuration. Helping a new user requires some subtly, as simply dumping a large configuration on a new user does not work well. An older user has had alot of time to add the customizations incrementally and adjust to them incrementally. The new user when they receive such a configuration first has to get the configuration running. If the advanced user has downloaded alot of third-party elisp the configuration file will likely generate errors and abort the loading of the configuration file. The new user also has to integrate the new features and behavior into their workflow which takes time, and is alot easier when done in small pieces. So split the setup means break up the user's .emacs file into parts: config/ .emacs style/ -> spell.el ; spell features -> lisp.el ; lisp programming features the .emacs file is carefully coded to make sure that it has a low risk of errors. Note that the style directory is not included in load-path deliberately. I named the directory style as a metaphor from the world of martial arts. In martial arts the harmonious blend of a set of techniques is often called a "fighting style" or some such thing. In this case turning on, adding, and customizing the various spelling features of Emacs to the point where spelling support is pervasive and well integrated constitutes a modular style of using Emacs. each of these large customization files such as spell.el have this basic form: phase 1: define a installer phase 2: check dependencies with require phase 3: perform customization My simple load-guard macro trapped errors during loading and suggests a installation method. The installation method does not necessarily need to be a package manager implemented in elisp. A table that maps features to package names for various package managers is sufficient. The final piece is a nice Emacs interface to the common package managers. With a configuration split up in the way I have described above it is alot easier to help another user use and learn the more advanced capabilities of Emacs. The advanced configuration is split up into parts like a curriculum. They can turn on all of "Guru Bob's" spelling features and integrate them into their workflow without having to learn at the same time all of his lisp tweaks, and other enhancements. A typical scenario would then go something like this: 1. User request's some help getting their Emacs setup with some of Bob's (Guru) features. 2. User receives The Guru's modular configuration and installs it. 3. The user chooses a feature set they are going to integrate into their work-flow, so they move the configuration for the features into the style directory where it will be picked up by the core .emacs file. 4. When they start emacs next it will likely not have necessary libraries, and so It tells them that the configuration is degraded and that they can type "install-foo" to fetch the necessary parts. 5. install foo determines what package manager is in use on the host, and searches the package system for the package names. It displays the search results for the user with a interface that generates the correct package manager commands and feeds them to the package manager via sudo or su if necessary. 6. with the libraries installed they can load the configuration file again. Since it aborted when the dependencies weren't met it didn't leave Emacs in a partially configured state. It doesn't require especially clever code to construct a configuration like this, just a little bit of elisp and a plan for how the configuration is organized. Assuming that Emacs is a good fit for the user they will likely pick it up fairly quickly, and soon write their own configuration. Without the beginning of the learning curve being broken up into steps it is very hard for even a eager new user to comprehend the potential of Emacs, especially when they are trying to quickly match the productivity of their old environment. The end result is a a middle ground for the new user. Instead of a dilemma of either starting from scratch and cherry-picking random elisp code without the elisp skills to integrate the code fragements properly, or choosing a massive jumbo configuration with another foreboding learning curve and no upgrade path, they can now incrementally adopt advanced features and configuration incrementally. A good question at this point is where does this fit into Emacs ? I have seen many "Jumbo configs" for java etc. A best practices guide for creating such configurations, along with some modes for the common package managers out there might be useful. > When I hav= > e a part > of the emacs setup that is only distributed with some of the > emacs forks, o= r none > I split the setup into a separate file. > > so I don't understand the issue. > > Inside the file for spelling support I start it with something > like this: > > What is "the file for spelling support"? I am totally lost. > Do you mean ispell.el? If not that, then what? Hopefully I have explained it a bit better, if not let me know.