From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: File-specific autoloads Date: Fri, 06 Jul 2007 20:28:35 +0200 Message-ID: <87ps35e698.fsf@ambire.localdomain> References: <87hcoilt68.fsf@ambire.localdomain> <87zm29eijw.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1183746578 8853 80.91.229.12 (6 Jul 2007 18:29:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2007 18:29:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 20:29:37 2007 connect(): Connection refused 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 1I6sYj-0003Un-5Q for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2007 20:29:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6sYi-0003P3-9V for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2007 14:29:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6sYc-0003I3-1f for emacs-devel@gnu.org; Fri, 06 Jul 2007 14:29:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6sYZ-0003Ac-8t for emacs-devel@gnu.org; Fri, 06 Jul 2007 14:29:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6sYZ-0003AV-5c for emacs-devel@gnu.org; Fri, 06 Jul 2007 14:29:27 -0400 Original-Received: from smtp-out3.libero.it ([212.52.84.43]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I6sYU-00070b-RO; Fri, 06 Jul 2007 14:29:23 -0400 Original-Received: from localhost (172.31.0.49) by smtp-out3.libero.it (7.3.120) id 4688F31B008EED6D; Fri, 6 Jul 2007 20:28:52 +0200 X-Scanned: with antispam and antivirus automated system at libero.it Original-Received: from smtp-out3.libero.it ([172.31.0.39]) by localhost (asav-out8.libero.it [192.168.32.36]) (amavisd-new, port 10024) with ESMTP id wLaqxSzxNOAa; Fri, 6 Jul 2007 20:28:52 +0200 (CEST) Original-Received: from outrelay08.libero.it (192.168.32.103) by smtp-out3.libero.it (7.3.120) id 4611FDB606ECF376; Fri, 6 Jul 2007 20:28:52 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFMmjkaXFSDt/2dsb2JhbAA Original-Received: from ppp-237-32.21-151.libero.it (HELO ambire.localdomain) ([151.21.32.237]) by OutRelay-b08.libero.it with ESMTP; 06 Jul 2007 20:28:52 +0200 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1I6sXj-0001WK-98; Fri, 06 Jul 2007 20:28:35 +0200 In-Reply-To: (Eli Zaretskii's message of "Fri\, 06 Jul 2007 19\:04\:53 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:74416 Archived-At: () Eli Zaretskii () Fri, 06 Jul 2007 19:04:53 +0300 That's an incorrect emulation of what "make autoloads" does: it _does_ modify the file. At least in my case, it did (I verified that with "cvs diff"). that's fine (no argument). we discuss that case below: > but regardless of cvs version quirks, let's look at the nature of the > changes: autoload processing changes a specified region; programmers > should not change that region manually. And we want to rely on that? we want to rely on it inasmuch as we designed it that way. if our design changes so that mixing autoload-processing regions and programmer regions is encouraged, then that would influence our downstream reliance. however, i see from cvs annotate autoload.el: 1.58 (rms 05-Aug-97): (defvar generated-autoload-file "loaddefs.el" 1.58 (rms 05-Aug-97): "*File \\[update-file-autoloads] puts autoloads into. 1.58 (rms 05-Aug-97): A `.el' file can set this in its local variables section to make its 1.71 (kwzh 27-Jun-99): autoloads go somewhere else. The autoload file is assumed to contain a 1.71 (kwzh 27-Jun-99): trailer starting with a FormFeed character.") which leads me to believe that autoload processing is not prone to any radical changes since it has worked for quite a while now (i could be wrong). Anyway, seeing those "M ps-print.el" lines in the output of "cvs up" is extremely annoying, because I'm used to take that as a sign that I have uncommitted changes in my sandbox. It also breaks the principle that files that are rewritten locally as part of the build process are not kept in CVS. these are separate issues that should be addressed separately. one approach to resolve the M status would be to request maintainers to regenerate and check in their newest ps-print.el or cl-loaddefs.el (regenerated) whenever any of the files that they serve as the autoload file for are changed. this is similar to the convention of checking in configure (regenerated) as well as configure.in. So I think this change in its current incarnation is for the worse. Maybe if the autoloads were written into files that are not in CVS I'd be happier. cvs already contains one generated file (configure script) and possibly others. i personally dislike that practice as well, but since we have already done the head-scratching for that file, we might as well apply the lessons to this situation. thi