From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T. V. Raman" Newsgroups: gmane.emacs.devel Subject: Re: Experimental features Date: Sat, 23 Jun 2007 18:43:34 -0700 Message-ID: <18045.52294.90516.146809@gargle.gargle.HOWL> References: <200706230800.23564.andreas.roehler@online.de> Reply-To: raman@users.sf.net NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1182649427 10209 80.91.229.12 (24 Jun 2007 01:43:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Jun 2007 01:43:47 +0000 (UTC) Cc: monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: andreas.roehler@online.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 24 03:43:45 2007 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 1I2H8h-0007GL-0s for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2007 03:43:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2H8g-0002Wa-Id for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2007 21:43:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2H8d-0002WP-B2 for emacs-devel@gnu.org; Sat, 23 Jun 2007 21:43:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2H8b-0002Vz-Ux for emacs-devel@gnu.org; Sat, 23 Jun 2007 21:43:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2H8b-0002Vw-Ob for emacs-devel@gnu.org; Sat, 23 Jun 2007 21:43:37 -0400 Original-Received: from alnrmhc12.comcast.net ([204.127.225.92]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I2H8a-0000bZ-3G; Sat, 23 Jun 2007 21:43:36 -0400 Original-Received: from localhost (c-71-202-191-236.hsd1.ca.comcast.net[71.202.191.236]) by comcast.net (alnrmhc12) with ESMTP id <20070624014334b1200qalaue>; Sun, 24 Jun 2007 01:43:35 +0000 Original-Received: by localhost (Postfix, from userid 1000) id 2AF2C12A47CF; Sat, 23 Jun 2007 18:43:34 -0700 (PDT) In-Reply-To: <200706230800.23564.andreas.roehler@online.de> X-Mailer: VM alpha-457 under Emacs 22.1.50.10 (i686-pc-linux-gnu) x-attribution: tvr X-detected-kernel: NetCache Data OnTap 5.x 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:73737 Archived-At: The other advantage in doing what you suggest is that external packages can evolve more rapidly than Emacs. Including things with core emacs is primarily a user convenience; but that then becomes an inconvenience if core Emacs includes an older version of an external package, because, now the user has to know to grab the unbundled package and install it such that it shadows what is bundled with Emacs. Thus, I believe: A) Core Emacs should unbundle --- not bundle more packages B) Core Emacs needs a light-weight means for users to discover and incorporate additional esxternal packages into their site.= >>>>> "Andreas" =3D=3D Andreas R=F6hler wri= tes: Andreas> Am Freitag, 22. Juni 2007 23:05 schrieb Stefan Andreas> Monnier: >> Release practice during Emacs-21 at least is that new >> features could only appear in new major releases, except >> for a few small exceptions. >>=20 >> I'd like to change that to make released Emacsen evolve >> faster. One way to do that would be to introduce the idea >> of "experimental" features which could be added to any >> minor release. >>=20 >> An experimental feature would be disabled by default and >> the code should be written in such a way that as long as >> the feature is enabled, it's clearly obvious that it >> cannot have any negative effect. >>=20 >> We'd then provide a way for the user to activate some of >> the experimental features from her .emacs file. After >> some time, we would promote the new feature such that it >> is not experimental any more. >>=20 >>=20 >> Stefan >>=20 Andreas>=20 Very good idea. But let's put the question more thoroughly: as Andreas> the realm of computing is vast and ever expands, you Andreas> have to give up the idea to incorporate any valid Andreas> program into core-Emacs sooner or later. Andreas>=20 Andreas> Emacs already is unnecessary big for most of the Andreas> purposes. Thus it starts not as quick as others, Andreas> risks not to be first choice for calling under Andreas> certain circumstances. That's a pity for me, because Andreas> I prefer it. Don't want to write any line without Andreas> it, even not to my mother. :) Andreas>=20 Andreas> I propose a more slim core emacs coming with an Andreas> install-shield, which lets users click features, Andreas> some of them may be marked as experimental too. Andreas>=20 Andreas> Given this, I would be glad to see common Andreas> third-party features as ESS, ECB, Emacspeak Andreas> etc. reachable too that way. Andreas>=20 Andreas> I'm aware this would mean a major work. However, it Andreas> must not be done at once. It offers great chances, Andreas> because it would ease the use for many people, thus Andreas> expanding the number of users. Andreas>=20 Andreas> Andreas Roehler Andreas>=20 Andreas>=20 Andreas> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F Andreas> Emacs-devel mailing list Emacs-devel@gnu.org Andreas> http://lists.gnu.org/mailman/listinfo/emacs-devel -- Best Regards, --raman Email: raman@users.sf.net WWW: http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk: tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman IRC: irc://irc.freenode.net/#emacs