Re: What a modern collaboration toolkit looks like

[Mike Mattie <codermattie@gmail.com>]

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

On Mon, 31 Dec 2007 16:27:07 -0800
Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > > Date: Mon, 31 Dec 2007 16:41:08 -0500
>   > > From: "Eric S. Raymond" <esr@thyrsus.com>
>   > > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
>   > > 
>   > > I proudly mentioned my work on VC-mode, and got majorly dumped
>   > > on for bothering with Emacs at all.  The kids out there think
>   > > we're a stagnant backwater, an old-boys club of bearded
>   > > grognards that has learned nothing and forgotten nothing for
>   > > the last decade.
>   > 
>   > Curiously enough, I'm having an opposite experience these days: a
>   > bunch of extremely able developers who work for years with MS
>   > Visual Studio came to respect Emacs, as a viable and powerful
>   > alternative to the bloated and dog-slow Studio, even on Windows,
>   > to say nothing of GNU/Linux (this is a dual-platform project,
>   > where software is developed to run on both systems).  All I
>   > needed to do is introduce them to some optional features, such as
>   > Speedbar, ebrowse, and gdb-ui, and craft a simple .emacs to bind
>   > the various Fn keys to compile/run/debug commands they were used
>   > to have.  After that, I never again heard anyone of them laughing
>   > at "stagnant backwater" that is Emacs.
> 
> Care to post an example of such .emacs? 
> Maybe it can be used as a skeleton for a package for such users, or
> maybe we can change some defaults to match such users' expectations.

I have tried to do something like this but I have constantly run into
what I think is the true issue facing Emacs, the fact that it is forked
almost to death.

There are three forks of Emacs for Mac OS X, cedet is maintained outside
of the mainline, the Ohio Lisp archive died ages ago, slime is third party,
and icicles distributes through the emacs wiki.

Why does Emacs branch, until the branches become so old that you are forced
to admit they are a fork ?

It may be that Emacs simply tries to set a higher standard for merging, a standard
that the current tools and practices do not support well. Or there may be an
artificial barrier.

As long as assembling a modern, slick Emacs consists of scavenging various
pieces scattered across the net with unreliable hosting, and uncertain maintainer-ship,
it's extremely hard to build a cross-platform Emacs. 

I have found the Emacs community to be one of the most responsive and skilled 
group of developers in open-source, but trying to straddle all the schisms to 
support users is really hard.

Here is a code example of how I am trying to solve this problem. When I have a part
of the emacs setup that is only distributed with some of the emacs forks, or none
I split the setup into a separate file.

I have a macro that traps errors on load.

(defmacro load-guard ( file error )
  "Trap errors from loading a file for robustness while initializing."
  `(condition-case nil
     (load (concat my-emacs-dir ,file))
     (error (progn
              ;; duplicate the message to both *Messages* as a log
              ;; and to the *scratch* buffer where it is highly visible.
              (message "initialization failed %s" ,error)
              (with-current-buffer "*scratch*"
                (goto-char (point-max))
                (insert (format "; !degraded configuration! %s\n" ,error)))
              ))
     ))


Inside the file for spelling support I start it with something like this:

(defun install-flyspell ()
  "install or update flyspell"
  (interactive)
  (dl-elisp "http://www-sop.inria.fr/mimosa/Manuel.Serrano/flyspell/flyspell-1.7n.el" "flyspell"))

(require 'flyspell)

config....


The idea is that if require fails then it raises an error, and the user has a function to install
the functionality. They can then re-execute the configuration once the necessary elisp is installed.
Each of the files must have all of the features required as require forms to ensure that it does not
configure features that are not installed.

This could be made into a much slicker macro that would generate the check,install defuns from a
nice syntax.

This scheme in practice really doesn't work all that well, because you need reliable hosting for the
packages, and you need the last 5 or 10 versions with the version encoded in the URL/path so you can
lock a config to a known good version tested against the other components. The provide/require
lacks version information. That is another killer. Emacs.app provides flyspell, but what version ?

I am not proposing this sort of lightweight package management as a solution, rather as an example
of the reality of trying to create an Emacs setup that includes all of the wonderful creativity
and innovation that is the hallmark of Emacs.

So why do Emacs branches last for years instead of months ? Why is Emacs forked to death ?
These are not rhetorical punctuations of a vision, but rather real questions.

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

[-- 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