From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Removing unloaded functions from auto-mode-alist. Date: Mon, 25 Apr 2005 00:00:44 +0200 Message-ID: <857jirrg1f.fsf@lola.goethe.zz> References: <87zmvu6ba2.fsf@xs4all.nl> <85ll7e68ei.fsf@lola.goethe.zz> <854qe2ihhi.fsf@lola.goethe.zz> <85oecagzwf.fsf@lola.goethe.zz> <874qdvc48k.fsf@xs4all.nl> <85fyxfrjal.fsf@lola.goethe.zz> <87is2balna.fsf@xs4all.nl> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1114380371 16253 80.91.229.2 (24 Apr 2005 22:06:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2005 22:06:11 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 25 00:06:06 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DPpEW-0005H7-Ao for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2005 00:05:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPpJu-0004No-SJ for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2005 18:11:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DPpJN-00041V-E7 for emacs-devel@gnu.org; Sun, 24 Apr 2005 18:10:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DPpJM-00040w-MB for emacs-devel@gnu.org; Sun, 24 Apr 2005 18:10:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPpJM-0002QG-Gh for emacs-devel@gnu.org; Sun, 24 Apr 2005 18:10:44 -0400 Original-Received: from [151.189.21.42] (helo=mail-in-02.arcor-online.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DPpD5-0007oW-8T for emacs-devel@gnu.org; Sun, 24 Apr 2005 18:04:15 -0400 Original-Received: from lola.goethe.zz (i53879025.versanet.de [83.135.144.37]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id EABF2138BE4; Mon, 25 Apr 2005 00:01:00 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 6DCD61C1E222; Mon, 25 Apr 2005 00:00:45 +0200 (CEST) Original-To: Lute Kamstra In-Reply-To: <87is2balna.fsf@xs4all.nl> (Lute Kamstra's message of "Sun, 24 Apr 2005 23:51:37 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:36349 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36349 Lute Kamstra writes: > David Kastrup writes: > >> Lute Kamstra writes: >> >>> Consider the following situation: >>> >>> function 'a is autoloaded: (autoload "blabla" ...). >>> function 'b is autoloaded: (autoload "other" ...). >>> function 'c is defined. >>> function 'd is unbound. >>> >>> "blabla" defines 'a, 'b, 'c, and 'd as functions. >>> >>> Do (require 'blabla) and then (unload-feature 'blabla). >>> >>> Currently, all four functions will be unbound by unload-feature. >>> You propose to let unload-feature restore both 'a and 'b to their >>> previous autoloads [1]. >> >> Sure. >> >>> But what should be done with 'c? >>> >>> I think restoring 'c to its previous definition would be the right >>> thing to do. >> >> Not at all. The purpose of unload-feature is to be able to restore >> a state, most particular to conserve memory. So unload-feature >> should not waste memory by keeping in effect a history of load >> sequences around. Its purpose should be confined to unloading >> those features that _can_ reasonably be unloaded. And that means >> no functions whatsoever that _redefine_ stuff. The main purpose of >> the autoload restoration is to restore autoloads into the package >> itself, not foreign autoloads. > > For me, it is most intuitive/logical that unload-feature tries to > undo the effects of loading the feature. If it can. > It is very uncommon that a feature redefines a function (or a > variable), so keeping track of such cases will not waste much > memory. But it is very common that one loads and evals one and the same file over and over. We don't want to keep a history of that. >> I think that unload-feature should in the case of c being redefined >> simply barf and refuse to unload the feature. > > That's quite extreme. And it would require you too keep track of > redefinitions. Of the fact that they happened. That is about one cons cell worth of data. Old definitions, in contrast, can take any amount of data. > Why not use that tracking machinery to just restore these rare > cases? They don't seem exactly rare to me. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum