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: Feature Request : autoload-form Date: Sun, 30 Mar 2008 14:35:08 -0700 Message-ID: <20080330143508.44888605@reforged> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/.qWIJmI5B05ac2ZF4XHr1V_"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Trace: ger.gmane.org 1206912964 26981 80.91.229.12 (30 Mar 2008 21:36:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2008 21:36:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 30 23:36:35 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 1Jg5Ca-0005Ck-Hb for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2008 23:36:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jg5By-0002KX-HD for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2008 17:35:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jg5Bv-0002K6-5n for emacs-devel@gnu.org; Sun, 30 Mar 2008 17:35:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jg5Bs-0002Jc-Ed for emacs-devel@gnu.org; Sun, 30 Mar 2008 17:35:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jg5Bs-0002JZ-5B for emacs-devel@gnu.org; Sun, 30 Mar 2008 17:35:48 -0400 Original-Received: from wa-out-1112.google.com ([209.85.146.176]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jg5Br-0002Zv-Jd for emacs-devel@gnu.org; Sun, 30 Mar 2008 17:35:47 -0400 Original-Received: by wa-out-1112.google.com with SMTP id k34so1639976wah.10 for ; Sun, 30 Mar 2008 14:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=Wco3UKfBooEh7U4jqsM39zNKamMyENRsnsFQQR2j/cQ=; b=iKynp7fzAQ+rcMbpz2ZBS9vTDJFwI5WhUE+eFlPz2g5qpGb9TuZoMN6EQahUpc9XIWm95mCwZeoouoex6iPpgMLZy1nndq1bmWBUX2OxGsN6MIKMcLeD4q2v4ajCSEC3BEVn8DEZQb+Bvq0BhoL1Y+qkjZWSPxBD9nbcwNOZQtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=LdmcM9DCd9OOl5Peb80olq5UNx6CBPCU1+rRS1xzKUDilBKDYUPunZ7q3SjHnhe87GyrYdBtZsRXprR8FWsP6mQ7d1CthPkh7sNb0QJKfIe+4k2c9LbKWsHyzjqPtXUYBz7HQJgfKXKLQpE/g+oeYc7uerh8Sy1hCsNX/JoeIUc= Original-Received: by 10.114.13.1 with SMTP id 1mr8626490wam.60.1206912943123; Sun, 30 Mar 2008 14:35:43 -0700 (PDT) Original-Received: from reforged ( [71.217.206.83]) by mx.google.com with ESMTPS id q20sm7350409pog.0.2008.03.30.14.35.41 (version=SSLv3 cipher=OTHER); Sun, 30 Mar 2008 14:35:41 -0700 (PDT) In-Reply-To: X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.8; 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:93955 Archived-At: --Sig_/.qWIJmI5B05ac2ZF4XHr1V_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Mar 2008 12:24:19 +0100 "paul r" wrote: > 2008/3/30, Richard Stallman : >=20 > > I don't think we should install this in Emacs, though. Something > > like autoload should be kept simple and limited. >=20 > I think of autoload as a particular case of the general need to > "eval-on-event-then-call". Therefore, I do not see why evaluating a > form is less simple than loading a file. Form evaluation is, indeed, > less limited but I don't see why it should be a disadvantage here. >=20 > > If loading a certain file needs load-path to be set a certain way, > > the user should simply set load-path that way, perhaps in .emacs. > > It is a bad idea to have files that only work right if load-path > > is temporarily changed; rather than adding a new file to Emacs > > to cope with that situation, it would be better to redesign the > > Lisp code that appears to need it. >=20 > You are understanding most of the problem I'm facing. I'll try to give > you some more information in a manner as concise as possible. > I wrote a system called TidyConfig for emacs. It is not a mode, it is > a system. Its ultimate goal is to allow people to share effectively > what usualy resides in .emacs. Some people want to do that, because > they have very similar usage profiles, although not exactly the same. > Users copies can be synced using a DVCS. The best example I see is > people in my company, who all use TidyConfig and this way avoid > duplicated efforts. To achieve that : > - I got rid of the monolithic .emacs, so that bits of configuration > go into dedicated "modules". There is a module for C-mode, one for > Muse-mode etc. One module resides in one file. Modules are shared in > your network of friends/colleagues ... anybody syncing with you, so > they are "network-specific" but not "user-specific". > - To allow fine-tuning, a user can use "module configuration file", > which is an other file, with personal tweaking in it. Those conf files > are not shared and are usually optional. They are user specific, and > private. Exemple : the ERC module does a lot of configuration, but it > can not set up username, password etc because this information is > user-specific. >=20 > Any module is optional, this is the whole point of this project. Each > user simply choose in a list what modules he wants to use. He can > chose to load them at startup time, or "later when needed". In this > last case, I obviously use autoload. >=20 > I could put, at beginning of *every* modules, a (load-file > "thisModuleConfigurationFile" t). This is what I did before, but I do > not find that elegant, nor fully satisfactory in many ways for the > needs, so it now is to the TidyConfig system to carry proper loading > of modules. >=20 > Here we are. I currently have no option to do so, except putting the > form I want to eval in a dummy file and registering this file with > autoload. This is now what I do, and please believe I don't feel > pround of that ugly hack :) >=20 > If you want to visit my upstream TidyConfig repository, and why not > give it a try, you can go to > http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary . It is > versionned through mercurial, so you can also do a "hg clone" of this > url. It could maybe be used as a playground for people here to try and > share some lisp before checking in into the trunk, and also to get > hands on DVCS. There is an up to date documentation in english. >=20 > Hope that was not too long ... Thanks. I wrote something very similar, but different on some design points. It boi= led down to my "modules" having a three part form: [define meta-data & hooks ] [ load w/require ] [ setup ] I would define things like install hooks before the loading part. If anythi= ng went wrong with loading needed libraries, my load function could execute the install hooks, and re-= evaluate the module. loading would be a bunch of require forms. The setup would configure and integrate the features. If you want to know more drop me a mail off-list. > -- Paul >=20 >=20 --Sig_/.qWIJmI5B05ac2ZF4XHr1V_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH8AeMdfRchrkBInkRAvV5AJ93jtBjqy4uILS1Fb+hcuY8NohANgCeL/iF rbFOxTw1HDpj/cAPgo5Ka2E= =nZ9G -----END PGP SIGNATURE----- --Sig_/.qWIJmI5B05ac2ZF4XHr1V_--