[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What a modern collaboration toolkit looks like
From: |
Mike Mattie |
Subject: |
Re: What a modern collaboration toolkit looks like |
Date: |
Fri, 4 Jan 2008 19:34:21 -0800 |
On Thu, 03 Jan 2008 04:50:57 -0500
Richard Stallman <address@hidden> 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.
signature.asc
Description: PGP signature
- Re: What a modern collaboration toolkit looks like, (continued)
- Re: What a modern collaboration toolkit looks like, Eli Zaretskii, 2008/01/01
- Re: What a modern collaboration toolkit looks like, John S. Yates, Jr., 2008/01/01
- Re: What a modern collaboration toolkit looks like, Agustin Martin, 2008/01/02
- Re: What a modern collaboration toolkit looks like, Richard Stallman, 2008/01/03
- Re: What a modern collaboration toolkit looks like, Richard Stallman, 2008/01/03
- Re: What a modern collaboration toolkit looks like,
Mike Mattie <=
- Re: What a modern collaboration toolkit looks like, Trey Jackson, 2008/01/04
- Re: What a modern collaboration toolkit looks like, Gianluca Della Vedova, 2008/01/04
- Re: What a modern collaboration toolkit looks like, Richard Stallman, 2008/01/05