From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Brent Goodrick Newsgroups: gmane.emacs.bugs Subject: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Date: Tue, 27 Jan 2009 07:54:09 -0800 Message-ID: <18815.11809.968195.804775@hungover.brentg.com> References: <18813.7599.138907.415045@hungover.brentg.com> Reply-To: Brent Goodrick , 2061@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1233072361 21414 80.91.229.12 (27 Jan 2009 16:06:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Jan 2009 16:06:01 +0000 (UTC) Cc: 2061@emacsbugs.donarmstrong.com, Brent Goodrick To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 27 17:07:11 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LRqS3-0004yA-Bh for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jan 2009 17:06:12 +0100 Original-Received: from localhost ([127.0.0.1]:46752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRqQk-0004Zv-ON for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jan 2009 11:04:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRqPY-0003jD-Bm for bug-gnu-emacs@gnu.org; Tue, 27 Jan 2009 11:03:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRqPW-0003gl-Dk for bug-gnu-emacs@gnu.org; Tue, 27 Jan 2009 11:03:34 -0500 Original-Received: from [199.232.76.173] (port=60097 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRqPV-0003gR-2T for bug-gnu-emacs@gnu.org; Tue, 27 Jan 2009 11:03:33 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:35768) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LRqPU-00055S-4c for bug-gnu-emacs@gnu.org; Tue, 27 Jan 2009 11:03:32 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0RG3TXu027743; Tue, 27 Jan 2009 08:03:30 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n0RG03Ks026569; Tue, 27 Jan 2009 08:00:03 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Brent Goodrick Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 27 Jan 2009 16:00:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 2061 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 2061-submit@emacsbugs.donarmstrong.com id=B2061.123307166025234 (code B ref 2061); Tue, 27 Jan 2009 16:00:03 +0000 Original-Received: (at 2061) by emacsbugs.donarmstrong.com; 27 Jan 2009 15:54:20 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0RFsCEK025225 for <2061@emacsbugs.donarmstrong.com>; Tue, 27 Jan 2009 07:54:13 -0800 Original-Received: by rv-out-0506.google.com with SMTP id k40so6466322rvb.1 for <2061@emacsbugs.donarmstrong.com>; Tue, 27 Jan 2009 07:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:mime-version :content-type:content-transfer-encoding:message-id:date:to:cc :subject:in-reply-to:references:x-mailer; bh=3qyKxjkpmxdbUUd7WPPGtDJpq58/7bJfXM7r7hXWzNU=; b=J+7JpW5Aphqr8wKM9fcaBYJi2lx9ue+cCCyHNo9hbYF4xon53YrABGXBMJXURLNecn LNVa9XKPK3H735zZdGCoEMhZzZdcWomzm3/2qbzTjkCNjhtCh3puxmKrapeQsumbvGhd Xgu2uMZhEfgTR36+I53HbpRd2OAHAdFZD8WWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:content-transfer-encoding:message-id :date:to:cc:subject:in-reply-to:references:x-mailer; b=I2434F5hU+JhLUUAr8PC/9TBDQfkKcr8UN6QuESx+prlUe+LWDUze3TdRj9HNeUioh oTMdnzkqRcDOQKG+wdyxiBEOMPt0cp0uwt69fAjAgBdlBo4z1bsDYM8IHoTnPaXVmWer RNod+d/+ZSsyMatsReTZfSF6Z7erwvIF8uoZM= Original-Received: by 10.141.28.2 with SMTP id f2mr103849rvj.217.1233071652074; Tue, 27 Jan 2009 07:54:12 -0800 (PST) Original-Received: from hungover.brentg.com.thisisbogus.com ([76.14.208.3]) by mx.google.com with ESMTPS id c20sm4470956rvf.8.2009.01.27.07.54.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jan 2009 07:54:11 -0800 (PST) In-Reply-To: X-Mailer: VM viewmail-609 under 23.0.60.1 (x86_64-unknown-linux-gnu) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 27 Jan 2009 11:03:34 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:24623 Archived-At: Juanma Barranquero writes: > On Mon, Jan 26, 2009 at 03:19, Brent Goodrick wrote: > > > When would the user ever prefer to load the .elc file after having > > modified the .el file? > > Whenever he saves the .el file, but the modifications aren't finished > (perhaps they don't even compile). > > In general, if Emacs loads the .el file when it is newer, you lose the > ability to decide whether you want the .el or the .elc. If Emacs > always loads the .elc (if present), you can decide you want the new > code loaded, by compiling the .el. The problem relates to when and how to notify the user that the stale .elc file is the one being loaded. During development, I just `eval-buffer' repeatedly on a .el file, always unaware that there is a stale .elc file lying in wait to confuse me the next time I reload the entire Emacs process/session. At init time, I only get a warning, among a ton of other benign warnings and messages, and that one critical warning is therefore not seen (of course, it is impractical to ask the user to read all of those messages). So, since that warning is not seen, effectively I lose the ability to decide which file, .el or .elc, to load. However, your concern is duly noted. Perhaps it is better not to change that hardcoded behavior in the way I suggested earlier. How about this (I'm not stuck on this nomenclature; modify to taste): Add the following logic to the C `load' function: Before loading either the .el or .elc file, test for the condition where the .el file is newer than the .elc file. If it is, then do the following: See if the `load-hook-stale-byte-compile-handlers' hook variable is set to non-nil. When it is non-nil, run the hook variable with `run-hook-with-args-until-success'. Each function the user has added to that hook variable would do any logic s/he wishes, including in my case to popup a minibuffer prompt asking what to do. When the hook function thus called returns a 'prefer-el-file symbol, `load' then loads the .el file and ignores the .elc file. Likewise, when the hook function returns the 'prefer-elc-file symbol, then load the .elc file but give no warning message and ignore the .el file. When nil is returned from the `run-hook-with-args-until-success' function, just load the .elc file and produce the stale file warning message as is done today (i.e., preserve existing behavior). In my case, I would actually allow the third case in the prompt, which is to byte compile the file and then return 'prefer-elc-file so that the newly byte compiled file is then loaded. That way, I don't pay the byte-compile-upon-every-save penalty as indicated below. > > > I could hack around this by fset'ing `load' to be my own function that > > removes the .elc file when the .el file is found to be newer, but that > > is an expensive operation involving calling such functions such as > > locate-file-internal to find both .el and .elc files, testing their > > modification date-time stamps, etc., operations that the `load' C > > function performs already. > > Isn't easier just to compile the .el file? If you're developing or > modifying a package, and want to try it at once, create a macro to > compile it as soon as you save it... I have tried doing that, but found it unworkable in practice, as byte-compiling upon each save ended up chewing up too much time during development (the byte-compile-upon-every-save penalty). Consider that I save frequently. :) A cheaper/dirtier arrangement that I have in place now is an after-save hook that simply deletes the associated .elc file if it exists. But that is a hack, so I am now trying to get the root problem addressed in the C code where it exists. Brent