Re: What a modern collaboration toolkit looks like

[Richard Stallman <rms@gnu.org>]

    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.

We ask people not to start off beginners with a customized Emacs.
A new users should learn a standard Emacs, and then customize it
if he wants to customize it.  But he shouldn't be led into using
something nonstandard before he knows the difference.

    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.

Do you think that enabling the spelling features of Emacs is complex?
If so, maybe we should simplify it.  That would be a better solution
to this problem, if it exists.


    each of these large customization files such as spell.el have this basic fo=
    rm:

    phase 1: define a installer

    phase 2: check dependencies with require

    phase 3: perform customization

Why is so much needed just to enable spelling features?

    1. User request's some help getting their Emacs setup with some of Bob's (G=
    uru) features.
    2. User receives The Guru's modular configuration and installs it.

If "Bob's features" refers to Lisp packages not included in Emacs,
then why not install them in the standard directory on the user's
machine?  There `load-library' will find them without any special
effort.