From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "paul r" Newsgroups: gmane.emacs.devel Subject: Re: Feature Request : autoload-form Date: Sun, 30 Mar 2008 12:24:19 +0100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1206876276 13646 80.91.229.12 (30 Mar 2008 11:24:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2008 11:24:36 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 30 13:25:07 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 1Jfvet-0002ct-Gn for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2008 13:25:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfveH-0007xk-HN for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2008 07:24:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfveB-0007vs-Go for emacs-devel@gnu.org; Sun, 30 Mar 2008 07:24:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfveA-0007vC-KG for emacs-devel@gnu.org; Sun, 30 Mar 2008 07:24:23 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfveA-0007ut-4Z for emacs-devel@gnu.org; Sun, 30 Mar 2008 07:24:22 -0400 Original-Received: from fg-out-1718.google.com ([72.14.220.154]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jfve8-0005Bm-QV for emacs-devel@gnu.org; Sun, 30 Mar 2008 07:24:21 -0400 Original-Received: by fg-out-1718.google.com with SMTP id d23so1483010fga.30 for ; Sun, 30 Mar 2008 04:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VRCp9W1/zNlhM3mnm4HeTQo16iHucwdvQScBcd47mSE=; b=HwxEjgWfTlaEI+HG66zjY2iROpm0xt30+QfnVlQJX1HXTFyKNlC+ih3xmUfmDGG2llwdShTTdq/CVK+ynvMmBVt6IGtaGaehrIOxnswvruP3eCqJ7jWLJ1AnIQXbGsPm8/DHmnjrVvwwRRKVd5PcdfD1qs9zx3ezAD6VoVxniIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NbS2dgy3e2opH3jgkkkjoSuT+LcUBrGApGhT4Rkp5lDckDV2I18dFnui5zdu4gmhHGvAagdkGguPIbVQsAkksxs7e9y0T9XcvP5n4aGX2R+QoOQsh9XFd2XCKtbz4tYJ855jUwo3un4DzOhyAKbSOVKCgYfX4BoWyadK0wGfhY4= Original-Received: by 10.82.184.2 with SMTP id h2mr13485019buf.1.1206876259287; Sun, 30 Mar 2008 04:24:19 -0700 (PDT) Original-Received: by 10.82.175.3 with HTTP; Sun, 30 Mar 2008 04:24:19 -0700 (PDT) In-Reply-To: Content-Disposition: inline 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:93894 Archived-At: 2008/3/30, Richard Stallman : > I don't think we should install this in Emacs, though. Something like > autoload should be kept simple and limited. 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. > 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. 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. 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. 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. 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 :) 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. Hope that was not too long ... Thanks. -- Paul