From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Mattie Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Mon, 31 Dec 2007 19:00:34 -0800 Message-ID: <20071231190034.12b0ed4a@reforged> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <20071231214108.GD26639@thyrsus.com> <200801010027.m010R74P025484@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1338003234==" X-Trace: ger.gmane.org 1199156498 30636 80.91.229.12 (1 Jan 2008 03:01:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Jan 2008 03:01:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 01 04:01:52 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J9XO3-0005hb-FF for ged-emacs-devel@m.gmane.org; Tue, 01 Jan 2008 04:01:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9XNh-0006gh-Fy for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2007 22:01:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9XNd-0006gS-Tk for emacs-devel@gnu.org; Mon, 31 Dec 2007 22:01:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9XNd-0006gF-BD for emacs-devel@gnu.org; Mon, 31 Dec 2007 22:01:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9XNd-0006gC-91 for emacs-devel@gnu.org; Mon, 31 Dec 2007 22:01:25 -0500 Original-Received: from wa-out-1112.google.com ([209.85.146.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J9XNc-0002YR-Nj for emacs-devel@gnu.org; Mon, 31 Dec 2007 22:01:25 -0500 Original-Received: by wa-out-1112.google.com with SMTP id k34so8007035wah.10 for ; Mon, 31 Dec 2007 19:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=gTIEvB36pDUtiRPo8cz7ep3CG6MnwESdEjXzAJODDf0=; b=udEnAbo42zoKCJAs9QDkzn/wWcL2Q1fgwWTGF9KBfrS9pHSSgYQpwAAFNDPAjXvIj5BrfokycWahwaao9ufrI7SzzObqdd77pa6RGGBMGcqomcUcEbFhb8Td0KmQdCJ0XdQuJ8tiN/0ve1yMvmyvoyjvN5RJmx1rUEqfx2kTESI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=rUPpH4lZM0lCEkdqaG71bxJi4R3/wo8QmX/d+aLjsm3c58sCT7LVXdiFAZg8UWaMluEfIS1duduR1LNOadSS3PKPmxzJhW3ng4aLxB3TORFPfcwjvfbHlzED63OlO28KS6oh14AYrOm7EyiFTsjQQKs3myiD7Ai5HZKWCjAwDEA= Original-Received: by 10.114.103.1 with SMTP id a1mr13977858wac.59.1199156483540; Mon, 31 Dec 2007 19:01:23 -0800 (PST) Original-Received: from reforged ( [71.217.198.62]) by mx.google.com with ESMTPS id n40sm22376169wag.34.2007.12.31.19.01.22 (version=SSLv3 cipher=OTHER); Mon, 31 Dec 2007 19:01:23 -0800 (PST) In-Reply-To: <200801010027.m010R74P025484@oogie-boogie.ics.uci.edu> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i686-pc-linux-gnu) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85795 Archived-At: --===============1338003234== Content-Type: multipart/signed; boundary="Sig_/MKRPNbIlusHL_BK8XY1SWI0"; protocol="application/pgp-signature"; micalg=PGP-SHA1 --Sig_/MKRPNbIlusHL_BK8XY1SWI0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 31 Dec 2007 16:27:07 -0800 Dan Nicolaescu wrote: > Eli Zaretskii writes: >=20 > > > Date: Mon, 31 Dec 2007 16:41:08 -0500 > > > From: "Eric S. Raymond" > > > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org > > >=20 > > > 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. > >=20 > > 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. >=20 > Care to post an example of such .emacs?=20 > 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 s= tandard 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 main= tainer-ship, it's extremely hard to build a cross-platform Emacs.=20 I have found the Emacs community to be one of the most responsive and skill= ed=20 group of developers in open-source, but trying to straddle all the schisms = to=20 support users is really hard. Here is a code example of how I am trying to solve this problem. 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. 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/flyspel= l-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 nece= ssary elisp is installed. Each of the files must have all of the features required as require forms t= o 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 i= n 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 flysp= ell, but what version ? I am not proposing this sort of lightweight package management as a solutio= n, 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 fo= rked to death ? These are not rhetorical punctuations of a vision, but rather real question= s. >=20 > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel --Sig_/MKRPNbIlusHL_BK8XY1SWI0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHeazSdfRchrkBInkRAkWgAKC5dHhSlqG5RJywv5FWtfiIxPu6HACfUMMI MOFP78VxE3mLcrvp58ecUGc= =6bbB -----END PGP SIGNATURE----- --Sig_/MKRPNbIlusHL_BK8XY1SWI0-- --===============1338003234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============1338003234==--