Re: What a modern collaboration toolkit looks like

[Mike Mattie <codermattie@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6199 bytes --]

On Thu, 03 Jan 2008 04:50:57 -0500
Richard Stallman <rms@gnu.org> 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel