From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: Removing unloaded functions from auto-mode-alist. Date: Sun, 24 Apr 2005 23:51:37 +0200 Message-ID: <87is2balna.fsf@xs4all.nl> 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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1114379624 14015 80.91.229.2 (24 Apr 2005 21:53:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2005 21:53:44 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 24 23:53:42 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DPp2b-00044r-Nx for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2005 23:53:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPp80-0008K0-AA for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2005 17:59:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DPp6p-0007op-OH for emacs-devel@gnu.org; Sun, 24 Apr 2005 17:57:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DPp6o-0007oW-V1 for emacs-devel@gnu.org; Sun, 24 Apr 2005 17:57:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPp6o-0006ka-Re for emacs-devel@gnu.org; Sun, 24 Apr 2005 17:57:46 -0400 Original-Received: from [194.109.24.33] (helo=smtp-vbr13.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DPp4J-00079R-QE; Sun, 24 Apr 2005 17:55:12 -0400 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr13.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3OLpbP8058070; Sun, 24 Apr 2005 23:51:37 +0200 (CEST) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1DPp0r-0002G2-00; Sun, 24 Apr 2005 23:51:37 +0200 Original-To: David Kastrup In-Reply-To: <85fyxfrjal.fsf@lola.goethe.zz> (David Kastrup's message of "Sun, 24 Apr 2005 22:50:26 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 64 X-Virus-Scanned: by XS4ALL Virus Scanner 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:36346 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36346 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. It is very uncommon that a feature redefines a function (or a variable), so keeping track of such cases will not waste much memory. > 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. Why not use that tracking machinery to just restore these rare cases? >> But that would be quite a substantial change. It's probably best to >> leave this alone until after the release. > > Lute, _any_ change in that area is best left alone. Richard has > already clearly stated that we are not going to fiddle with it before > the release, and I can only agree. The current state of brokenness > has been there for a long time, and nobody really complained. We > can't hope to get a serious amount of testing for this sort of stuff > in before the release. And the effects might be memory leakage and > similar hard to find things that take people months to figure out. > > We can't invest the time to make sure that nothing like this will > happen. Ok. Lute.