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: Sun, 24 Apr 2005 22:32:11 +0200 Message-ID: <85oec3rk50.fsf@lola.goethe.zz> References: <87zmvu6ba2.fsf@xs4all.nl> <85ll7e68ei.fsf@lola.goethe.zz> <854qe2ihhi.fsf@lola.goethe.zz> <8764yi4awh.fsf@xs4all.nl> <873btlsalu.fsf@xs4all.nl> <87pswo84vv.fsf@xs4all.nl> <857jiucz6r.fsf@lola.goethe.zz> <87oec5p5rq.fsf@xs4all.nl> <85fyxhcff8.fsf@lola.goethe.zz> <87ekd0apu8.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 1114375209 10778 80.91.229.2 (24 Apr 2005 20:40:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2005 20:40:09 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 24 22:40:06 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DPntU-000570-GZ for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2005 22:39:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPnys-0007CW-Fw for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2005 16:45:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DPnyR-0007Bo-DP for emacs-devel@gnu.org; Sun, 24 Apr 2005 16:45:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DPnyQ-0007B5-1H for emacs-devel@gnu.org; Sun, 24 Apr 2005 16:45:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPnyP-0006wZ-US for emacs-devel@gnu.org; Sun, 24 Apr 2005 16:45:01 -0400 Original-Received: from [151.189.21.47] (helo=mail-in-07.arcor-online.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DPnpW-00031z-QN; Sun, 24 Apr 2005 16:35:51 -0400 Original-Received: from lola.goethe.zz (i53879025.versanet.de [83.135.144.37]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 4BB03128B91; Sun, 24 Apr 2005 22:32:27 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 03FF71C1E222; Sun, 24 Apr 2005 22:32:11 +0200 (CEST) Original-To: Lute Kamstra In-Reply-To: <87ekd0apu8.fsf@xs4all.nl> (Lute Kamstra's message of "Sun, 24 Apr 2005 22:21:03 +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:36339 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36339 Lute Kamstra writes: > David Kastrup writes: > > [...] > >> Well, the idea explored a bit later later was that "load" will >> record autoloads, but not do anything with them by itself, instead >> letting "provide" handle it. > > Ah, now I understand your post. I think letting provide record > autoloads is a bad idea. provide can occur anywhere in a file. So > when provide records autoloads it won't record the autoloads that > get replaced after that position. No, the idea was that load initiates the recording of autoload data alright, but will throw the recorded data away at the end of the load unless a `provide' occured at its top level. If the provide occured at the top level of the load, then the end of the load will tag all the functions with the autoload data, like do_autoload does now at the end of its load sequence. So the "provide" merely sets a flag, and this flag causes the encompassing load not to throw the collected previous autoload data away at the end of the load sequence, but use it for marking the changed functions with the old autoloads in their properties. Clearer now? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum