From bgoodr@gmail.com Sun Jan 25 18:19:41 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 26 Jan 2009 02:19:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.3 required=4.0 tests=FOURLA,FVGT_m_MULTI_ODD, IMPRONONCABLE_2,MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0Q2Jbje032372 for ; Sun, 25 Jan 2009 18:19:38 -0800 Received: from mx10.gnu.org ([199.232.76.166]:48961) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LRH32-0003xO-OS for emacs-pretest-bug@gnu.org; Sun, 25 Jan 2009 21:18:00 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LRH4X-0000nZ-Bj for emacs-pretest-bug@gnu.org; Sun, 25 Jan 2009 21:19:36 -0500 Received: from rv-out-0708.google.com ([209.85.198.247]:28675) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRH4W-0000nK-RC for emacs-pretest-bug@gnu.org; Sun, 25 Jan 2009 21:19:33 -0500 Received: by rv-out-0708.google.com with SMTP id k29so6698020rvb.6 for ; Sun, 25 Jan 2009 18:19:31 -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:subject :x-mailer; bh=8ojJROLaxt+6KSq7XKZDIVh8NqsxcPtsat0N+JnfF18=; b=MhytClgczWpTKjMHgYndthdNGQTYwaZuQR8fI2tdswlKihBSVNZrqsf6WUITsnCyKQ jj1rcb8syADlkShb+ReujgVmkzyntZqgJExtYe6hHEz/sA/BkEUWNxhO7SJIVdCXZmVN 0s3YGEB3fMnh9ZSwiFPFdWHylWxofUuaTAKQw= 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:subject:x-mailer; b=tkxuJy1URTG0irdz+uz4bHDzEGiqouOLfBrQbUET74LHDCfecWLVIJxmFqpuuOz/HM DorOLvXkWJP/rQTZRUPnHj2+gTCM9XFupONi3AR1jOE2NVilUk/fTBsXvdZtBUjXqomM gyXv1b7N753RsN4JjTy9eB4FltQgFhO8WsW/o= Received: by 10.141.101.16 with SMTP id d16mr1257498rvm.208.1232936370949; Sun, 25 Jan 2009 18:19:30 -0800 (PST) Received: from hungover.brentg.com.thisisbogus.com ([76.14.208.3]) by mx.google.com with ESMTPS id b8sm29490340rvf.9.2009.01.25.18.19.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Jan 2009 18:19:30 -0800 (PST) From: Brent Goodrick MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18813.7599.138907.415045@hungover.brentg.com> Date: Sun, 25 Jan 2009 18:19:27 -0800 To: emacs-pretest-bug@gnu.org Subject: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file 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, 2) Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: The load function will load a .elc file even if the .el file is newer than the .elc file. There are warnings issued, but it is likely that the message is lost in the ton of messages that usually are emitted, especially during Emacs invocation. When would the user ever prefer to load the .elc file after having modified the .el file? My suggestion is to add a customizable preference variable called, say, load-prefer-newer-lisp-files (that needs a better name), that is recognized by the load function (defined in C code). When load-prefer-newer-lisp-files is non-nil, and when there is a .el and .elc file, and when the .el file is newer than the .elc file, it loads the .el file and not the .elc file (and possibly emits a warning of this action). Having it be a customizable preference variable avoids surprising other users who are used to the existing behavior. 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. Hence, why I think it is best to change the load function to allow for both approaches via a preference variable. Thanks! Brent If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /home/brentg/emacs_from_source/install/share/emacs/23.0.60/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.11) of 2009-01-25 on hungover Windowing system distributor `The X.Org Foundation', version 11.0.10402000 configured using `configure '--with-x-toolkit' '--prefix=/home/brentg/emacs_from_source/install'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: erc-list-mode: t erc-menu-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-track-minor-mode: t erc-match-mode: t erc-button-mode: t erc-netsplit-mode: t desktop-save-mode: t iswitchb-mode: t erc-ring-mode: t erc-services-mode: t erc-networks-mode: t erc-fill-mode: t erc-stamp-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-move-to-prompt-mode: t erc-readonly-mode: t display-time-mode: t shell-dirtrack-mode: t delete-selection-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: 1 transient-mark-mode: t abbrev-mode: t Recent input: C-p C-p C-p C-p M-f M-f SPC f o r m C-e M-b M-f SPC t h e SPC . e l SPC f i l e SPC i n t o SPC a SPC . e l c SPC f i l e C-d C-a M-q C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-n C-n C-n C-e C-b SPC f o r SPC d e m o n s t r a t i o n SPC p u r o p o o s e s C-a C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-b M-b M-b M-b f o r SPC M-f M-f M-q M-f M-f C-b , SPC w h i c h SPC i s SPC SPC a SPC l i C-SPC M-b M-b M-b w r o n g SPC b e c a u s e SPC t h e SPC . e l c SPC f i l e SPC d o e s SPC i n e d e e d SPC e x i s t M-q C-a C-n C-n C-n C-n C-n C-n M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f C-n C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-c C-c y e s M-SPC M-x r e p p o r t M-P Recent messages: /home/brentg/.authin: 100% (398/398) 334 VXNlcm5hbWU6 334 UGFzc3dvcmQ6 235 2.7.0 Accepted 250 2.1.0 OK k41sm12274699rvb.3 250 2.1.5 OK k41sm12274699rvb.3 354 Go ahead k41sm12274699rvb.3 250 2.0.0 OK 1232907223 k41sm12274699rvb.3 221 2.0.0 closing connection k41sm12274699rvb.3 Sending...done From eliz@gnu.org Sun Jan 25 20:08:57 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 26 Jan 2009 04:08:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout7.012.net.il (mtaout7.012.net.il [84.95.2.19]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0Q48q7p028065 for <2061@emacsbugs.donarmstrong.com>; Sun, 25 Jan 2009 20:08:54 -0800 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KE2008008LM1T00@i-mtaout7.012.net.il> for 2061@emacsbugs.donarmstrong.com; Mon, 26 Jan 2009 06:09:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.255.234]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KE2009518UX7H10@i-mtaout7.012.net.il>; Mon, 26 Jan 2009 06:09:03 +0200 (IST) Date: Mon, 26 Jan 2009 06:08:43 +0200 From: Eli Zaretskii Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file In-reply-to: <18813.7599.138907.415045@hungover.brentg.com> X-012-Sender: halo1@inter.net.il To: Brent Goodrick , 2061@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <18813.7599.138907.415045@hungover.brentg.com> > From: Brent Goodrick > Date: Sun, 25 Jan 2009 18:19:27 -0800 > Cc: > > When would the user ever prefer to load the .elc file after having > modified the .el file? When you are working on the .el file and it is not ready yet, or buggy. > My suggestion is to add a customizable preference variable called, > say, load-prefer-newer-lisp-files (that needs a better name), that is > recognized by the load function (defined in C code). When > load-prefer-newer-lisp-files is non-nil, and when there is a .el and > .elc file, and when the .el file is newer than the .elc file, it loads > the .el file and not the .elc file (and possibly emits a warning of > this action). Yes, but please not now, not before Emacs 23.1 is released. We are in feature freeze. From lekktu@gmail.com Mon Jan 26 00:46:04 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 26 Jan 2009 08:46:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f10.google.com (mail-ew0-f10.google.com [209.85.219.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0Q8jul1001044 for <2061@emacsbugs.donarmstrong.com>; Mon, 26 Jan 2009 00:45:58 -0800 Received: by ewy3 with SMTP id 3so6893308ewy.1 for <2061@emacsbugs.donarmstrong.com>; Mon, 26 Jan 2009 00:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iM4l+CelFXcLG+gaWHo/TwZZB3byok4x8zHRJHfyb6M=; b=koAsPx+rZAtyznpX2Jw/si4m8k3oA2CnMW9tzKZ8g0TOpJOL28zSpUlHaDKi9jSE2L Qpo2nawi1ZxB5RUaH1gQ98qtLPOkBQNek627nuwAVil1Hf6jNy8oJ29pW1XdwGqb9rGg BGn17YKDszzqa4Au8/T3CG//9A2yOHM2PrLUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rhh0WRZ7jbtDYaUFnlyrJf79LBPxgnL5VRDS6tmLvk2iqKuf0vCma3WOxeq6JiuiYP wqAVUA9vBDQ/Yenb3CG6SIaYSU9P7zA3ySpVp1bIxArhFI8hH5vQ7iBbyNkkfY6QKgF6 6Helx2nYiCWD74u4k44j6AgIF8dJ/jw3pQyh4= MIME-Version: 1.0 Received: by 10.210.41.14 with SMTP id o14mr854703ebo.22.1232959550444; Mon, 26 Jan 2009 00:45:50 -0800 (PST) In-Reply-To: <18813.7599.138907.415045@hungover.brentg.com> References: <18813.7599.138907.415045@hungover.brentg.com> Date: Mon, 26 Jan 2009 09:45:50 +0100 Message-ID: Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file From: Juanma Barranquero To: Brent Goodrick Cc: 2061@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. > 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... Juanma From lekktu@gmail.com Mon Jan 26 00:47:55 2009 Received: (at control) by emacsbugs.donarmstrong.com; 26 Jan 2009 08:47:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.3 required=4.0 tests=MISSING_SUBJECT,NOSUBJECT, VALID_BTS_CONTROL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f10.google.com (mail-ew0-f10.google.com [209.85.219.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0Q8lpup001094 for ; Mon, 26 Jan 2009 00:47:53 -0800 Received: by ewy3 with SMTP id 3so6894511ewy.1 for ; Mon, 26 Jan 2009 00:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=oVkpWSmLwD0B9SIoZ+5kqwXll1Nq8VvIjGT43wm5NW8=; b=IGXpXuNofNw36fFjkMGgyYPp4/uhyUXUB1xu4EhQ9BbffDNeWiKjHOdobetgE824hI NgmW9EfFT7MvMvwrDZRMTe2ZhCWth7qnzXJmn/jNcvgWlf1VXgab4QaQgYSvoAyORftY K8E+fyoj+UQb9KpoC677kVzbRlChxd2czNIrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZvGZPtXWJ4Pnw+HSppgPBy1Pxt8ADiZFO7lx5ZC5SJkSUY4iO7iTfbgEbIMaoXRQPq FnXddp92i6bUfbculBTAC1U7ggqSKyiOIQ/ClQ+5VkfoVtANV+18lSxVX1Og8tGjy/CC yrYGlTo2jlAVC4IrcV/OjKpFVHRQV/y2h4rV4= MIME-Version: 1.0 Received: by 10.210.12.13 with SMTP id 13mr2266995ebl.12.1232959662953; Mon, 26 Jan 2009 00:47:42 -0800 (PST) Date: Mon, 26 Jan 2009 09:47:42 +0100 Message-ID: Subject: From: Juanma Barranquero To: control@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit severity 2061 wishlist quit From rms@gnu.org Mon Jan 26 08:33:15 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 26 Jan 2009 16:33:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0QGX2Zp022145; Mon, 26 Jan 2009 08:33:03 -0800 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LRUMu-0007EK-NT; Mon, 26 Jan 2009 11:31:24 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Brent Goodrick , 2061@debbugs.gnu.org CC: emacs-pretest-bug@gnu.org, bug-submit-list@donarmstrong.com, bug-gnu-emacs@gnu.org In-reply-to: <18813.7599.138907.415045@hungover.brentg.com> (message from Brent Goodrick on Sun, 25 Jan 2009 18:19:27 -0800) Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Reply-to: rms@gnu.org References: <18813.7599.138907.415045@hungover.brentg.com> Message-Id: Date: Mon, 26 Jan 2009 11:31:24 -0500 When would the user ever prefer to load the .elc file after having modified the .el file? If you have written changes which are incomplete and not ready to be executed. This feature gives you control over when to start running your changes: you control it by when you compile the files. It is important and it is easy to use. From bgoodr@gmail.com Tue Jan 27 07:09:09 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 27 Jan 2009 15:09:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0RF921C013961 for <2061@emacsbugs.donarmstrong.com>; Tue, 27 Jan 2009 07:09:03 -0800 Received: by rv-out-0506.google.com with SMTP id k40so6447467rvb.1 for <2061@emacsbugs.donarmstrong.com>; Tue, 27 Jan 2009 07:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:message-id:date :mime-version:content-type:content-transfer-encoding:to:cc:subject :in-reply-to:references:x-mailer; bh=d2jeGnyw8hkNQRti3D50dl4BZOT+BObL5d8dSGhcIvA=; b=rTCYCykBNQ/TuUqI56tLX5cNw2nsCd35RMKFuVALB9LlgZbBFq9FZisPNfgNAoJq/W raDDi7VmojSV98VfmAAJD42zUvQ8Oqgr3Mp5aftsy0Ramn3Yb0n9Mf0mU3XaQuyQSkQc fArOMwcFs00VYIQrEvSRqvM3V+tj9fKD8uxiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:message-id:date:mime-version:content-type :content-transfer-encoding:to:cc:subject:in-reply-to:references :x-mailer; b=esGL1PDhEqkIMbJLhbmJGAg7shC80OL3WaYSNvyXEn4akjVvTSSj5gW83IZE8R2nFR SWL7Zn+WvWPiLIZoNZN+KBifS9e6gheBpShiERK9E+022kB7LBNHX0F/iFh20iWIg7cH Bjpft1yH1GnZKbYckI4oRGWug1TFROM578KS8= Received: by 10.141.162.5 with SMTP id p5mr471rvo.193.1233068941687; Tue, 27 Jan 2009 07:09:01 -0800 (PST) Received: from hungover.brentg.com.thisisbogus.com ([76.14.208.3]) by mx.google.com with ESMTPS id g31sm1255432rvb.4.2009.01.27.07.09.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jan 2009 07:09:00 -0800 (PST) From: Brent Goodrick Message-ID: <18815.9099.40937.264917@hungover.brentg.com> Date: Tue, 27 Jan 2009 07:08:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eli Zaretskii Cc: Brent Goodrick , 2061@debbugs.gnu.org Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file In-Reply-To: References: <18813.7599.138907.415045@hungover.brentg.com> X-Mailer: VM viewmail-609 under 23.0.60.1 (x86_64-unknown-linux-gnu) Eli Zaretskii writes: > Yes, but please not now, not before Emacs 23.1 is released. We are in > feature freeze. Agreed. I was unaware of the release schedule. Brent From bgoodr@gmail.com Tue Jan 27 07:54:20 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 27 Jan 2009 15:54:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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= Received: by 10.141.28.2 with SMTP id f2mr103849rvj.217.1233071652074; Tue, 27 Jan 2009 07:54:12 -0800 (PST) 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) From: Brent Goodrick MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18815.11809.968195.804775@hungover.brentg.com> Date: Tue, 27 Jan 2009 07:54:09 -0800 To: Juanma Barranquero Cc: Brent Goodrick , 2061@debbugs.gnu.org Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file In-Reply-To: References: <18813.7599.138907.415045@hungover.brentg.com> X-Mailer: VM viewmail-609 under 23.0.60.1 (x86_64-unknown-linux-gnu) 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 From bgoodr@gmail.com Tue Jan 27 07:56:24 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 27 Jan 2009 15:56:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0RFuLCb026437 for ; Tue, 27 Jan 2009 07:56:22 -0800 Received: from mail.gnu.org ([199.232.76.166]:59768 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LRqGw-0007Xn-EH for emacs-pretest-bug@gnu.org; Tue, 27 Jan 2009 10:54:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LRqIV-00049n-TD for emacs-pretest-bug@gnu.org; Tue, 27 Jan 2009 10:56:20 -0500 Received: from rv-out-0708.google.com ([209.85.198.249]:14169) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRqIV-00049Z-Ik; Tue, 27 Jan 2009 10:56:19 -0500 Received: by rv-out-0708.google.com with SMTP id k29so7615651rvb.6 for ; Tue, 27 Jan 2009 07:56:17 -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=E12mi1m3twdldsYHt2M+EwuNmMI7wP3yXatrMlbdp0M=; b=WRn0DoVXWrZvxt1l2IyX3z2PP0WzEX/iAfWDxlLctD93ZOWQOPQOlziaUW9TaQRLny hMCg5o/HIyojBYuN+mICkzKJed37K/qTOUNWvd9qDyJDxGK8pY/usiNE7hWeZucCorvM 7ZWuHVOwyVvqMhZHB+TCvZl0HIJIUoqmNLpBE= 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=ItnBWVKySDf2QwOjzQE9a8sca4tMtPWPg/MI1Hk3rHOhRnMTHNQe6/mZ9DFJyJsJj3 unJ9xTcOvwM1T7CvZpiMuW/XqPXeZF+KgzI9jN2XM1oMbXiwxSiFx2OYsrI1+HI/K7wH RHt4e0EiZAW9hXBrwOo7eAggGTsXT6/wVV7D0= Received: by 10.141.152.9 with SMTP id e9mr2554735rvo.189.1233071777917; Tue, 27 Jan 2009 07:56:17 -0800 (PST) Received: from hungover.brentg.com.thisisbogus.com ([76.14.208.3]) by mx.google.com with ESMTPS id k37sm15716864rvb.1.2009.01.27.07.56.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jan 2009 07:56:17 -0800 (PST) From: Brent Goodrick MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18815.11935.529593.18833@hungover.brentg.com> Date: Tue, 27 Jan 2009 07:56:15 -0800 To: rms@gnu.org Cc: Brent Goodrick , 2061@debbugs.gnu.org, emacs-pretest-bug@gnu.org, bug-submit-list@donarmstrong.com, bug-gnu-emacs@gnu.org Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file In-Reply-To: References: <18813.7599.138907.415045@hungover.brentg.com> 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, 2) X-CrossAssassin-Score: 2 Richard M Stallman writes: > When would the user ever prefer to load the .elc file after having > modified the .el file? > > If you have written changes which are incomplete and not ready > to be executed. > > This feature gives you control over when to start running your > changes: you control it by when you compile the files. It is > important and it is easy to use. See a new proposal I just emailed to this thread which I think addresses the problem a bit better than just changing the default `load' behavior as I originally suggested. Brent From lekktu@gmail.com Tue Jan 27 18:06:23 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 28 Jan 2009 02:06:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f10.google.com (mail-ew0-f10.google.com [209.85.219.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0S26Jjx019690 for <2061@emacsbugs.donarmstrong.com>; Tue, 27 Jan 2009 18:06:21 -0800 Received: by ewy3 with SMTP id 3so9395101ewy.1 for <2061@emacsbugs.donarmstrong.com>; Tue, 27 Jan 2009 18:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+NJfCsEKBV0QhAC6pZLuwvqVVSTmq6zOWi/0Rxp4RRc=; b=WIj0QNuUwubPCbea18sojBVn+roYn7nnv4amsXgqUbA2mpACpzejPF+oV/F1gjbPHF 7/PeAmSytREbizSUoNIBh4UeCtzM+wjr2kHz6CQnj0j7kNOlxmaVn5nZUPjnfFWuSUvj /rqCayI+CNn5Qh3yXf4sMie1UgNe/c9Nf7Zps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XrrfQG/6YlOZMLl6Mk4tylw5xXqL17XyHaUriQOe0bxcWnLxTmeaq8RvpF2ub1tpLM qbhYXoZu628CLWwx/aDKl4lVmGeuICnryqBwQTfpvx0st3ANmB07h3lJ63zWkRPt+0Gb 5Lwv8z0thdKm/WqY49oSICNgqKbaV7iPg4xyw= MIME-Version: 1.0 Received: by 10.210.45.17 with SMTP id s17mr7090231ebs.93.1233108373929; Tue, 27 Jan 2009 18:06:13 -0800 (PST) In-Reply-To: <18815.11809.968195.804775@hungover.brentg.com> References: <18813.7599.138907.415045@hungover.brentg.com> <18815.11809.968195.804775@hungover.brentg.com> Date: Wed, 28 Jan 2009 03:06:13 +0100 Message-ID: Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file From: Juanma Barranquero To: Brent Goodrick Cc: 2061@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Tue, Jan 27, 2009 at 16:54, Brent Goodrick wrote: > 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. If you're going to modify/test the package with eval-buffer, you should make sure there's no .elc sitting around. > 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). As you know, that's trivially fixed: (add-hook 'emacs-startup-hook (lambda () (with-current-buffer (get-buffer "*Messages*") (goto-char (point-min)) (while (re-search-forward "[Ss]ource file .*? newer" nil t) (warn "%s" (buffer-substring (line-beginning-position) (line-end-position))))))) > 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). That would work, but it is IMHO too much (interface, not code) complexity for little gain. In most cases, having a .elc older than its corresponding .el is a bug (or, let's call it, a temporary situation), so getting a warning to remind the user about fixing it seems much more economical. That said, sometimes I would've liked to have a hook that runs when a file is loaded; or the ability to defadvice Fload (you can, except that Fload is also called from C code, for example for autoloads). > 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. :) I didn't mean to byte-compile on saving, I meant to byte-compile on eval-buffer (or whatever method you use to test your code). > But that is a hack, so I am now trying to get the root problem > addressed in the C code where it exists. I agree that greater control over the loading process could sometimes be useful; but I don't think this is a compelling use case. Juanma From geb-bug-gnu-emacs@m.gmane.org Wed Jan 28 00:29:53 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Jan 2009 08:29:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0S8TlWa018328 for ; Wed, 28 Jan 2009 00:29:50 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LS5nv-0006Yl-LT for bug-gnu-emacs@gnu.org; Wed, 28 Jan 2009 03:29:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LS5nt-0006XE-Vi for bug-gnu-emacs@gnu.org; Wed, 28 Jan 2009 03:29:47 -0500 Received: from [199.232.76.173] (port=45137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LS5nt-0006X8-OK for bug-gnu-emacs@gnu.org; Wed, 28 Jan 2009 03:29:45 -0500 Received: from main.gmane.org ([80.91.229.2]:41077 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LS5nt-0006xL-24 for bug-gnu-emacs@gnu.org; Wed, 28 Jan 2009 03:29:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LS5nm-0007hF-TH for bug-gnu-emacs@gnu.org; Wed, 28 Jan 2009 08:29:38 +0000 Received: from c-67-161-145-183.hsd1.co.comcast.net ([67.161.145.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jan 2009 08:29:38 +0000 Received: from kevin.d.rodgers by c-67-161-145-183.hsd1.co.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jan 2009 08:29:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Kevin Rodgers Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Date: Wed, 28 Jan 2009 01:29:37 -0700 Lines: 39 Message-ID: References: <18813.7599.138907.415045@hungover.brentg.com> <18815.11809.968195.804775@hungover.brentg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-67-161-145-183.hsd1.co.comcast.net User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) In-Reply-To: Sender: news X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Juanma Barranquero wrote: > On Tue, Jan 27, 2009 at 16:54, Brent Goodrick wrote: ... >> 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). > > That would work, but it is IMHO too much (interface, not code) > complexity for little gain. In most cases, having a .elc older than > its corresponding .el is a bug (or, let's call it, a temporary > situation), so getting a warning to remind the user about fixing it > seems much more economical. > > That said, sometimes I would've liked to have a hook that runs when a > file is loaded; or the ability to defadvice Fload (you can, except > that Fload is also called from C code, for example for autoloads). Yes, before-load-hook and after-load-hook would be generally useful if load-file-name were set to load's FILE argument when they're run. -- Kevin Rodgers Denver, Colorado, USA From bgoodr@gmail.com Mon Feb 2 08:07:11 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 2 Feb 2009 16:07:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-gx0-f20.google.com (mail-gx0-f20.google.com [209.85.217.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n12G78TC019222 for <2061@emacsbugs.donarmstrong.com>; Mon, 2 Feb 2009 08:07:09 -0800 Received: by gxk13 with SMTP id 13so1275962gxk.1 for <2061@emacsbugs.donarmstrong.com>; Mon, 02 Feb 2009 08:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eKh3iFMacwcRi3WkSUUZQlQlCdLyKZYL0SmHXZeXUYI=; b=JYLelU05UY8EoKfgyzXAxxgogzqngt5GX2/gIxQT+9aY2Y+TbGP/S2wXhdkm08Qjqc epCldeey7yG61G4J2TFX4oEwQ5rpANo4dmwl2Pr2tOvZDqwm/+G2YdyVT+gHm+XV5lyW 3gHFlkXJdIrrosuGngVRzUOG+mPIgtATB0iIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=La7zXc4Q/gk4z6kw+aEOKXOy7kiUtw5uQhxTFaPLUm6KKyUYbcWNHPYPqudQZaAo+o Y+b73hEV1UcQ+DjiBSbwEqSk1kltW2zVT2VlIkFlD8Q6XijrXNoxqhQbhhe8eSm3R/KU MUbs+BF1rRP1zFlw8K/r8KcupUWUrvs9MgKG8= MIME-Version: 1.0 Received: by 10.90.101.17 with SMTP id y17mr1212835agb.106.1233590822656; Mon, 02 Feb 2009 08:07:02 -0800 (PST) In-Reply-To: References: <18813.7599.138907.415045@hungover.brentg.com> <18815.11809.968195.804775@hungover.brentg.com> Date: Mon, 2 Feb 2009 08:07:02 -0800 Message-ID: Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file From: Brent Goodrick To: Juanma Barranquero Cc: 2061@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I won't pursue this any further. You all have given me some useful workarounds that I will explore further. Thanks Brent On 1/27/09, Juanma Barranquero wrote: > On Tue, Jan 27, 2009 at 16:54, Brent Goodrick wrote: > >> 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. > > If you're going to modify/test the package with eval-buffer, you > should make sure there's no .elc sitting around. > >> 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). > > As you know, that's trivially fixed: > > (add-hook 'emacs-startup-hook > (lambda () > (with-current-buffer (get-buffer "*Messages*") > (goto-char (point-min)) > (while (re-search-forward "[Ss]ource file .*? newer" nil t) > (warn "%s" (buffer-substring (line-beginning-position) > (line-end-position))))))) > > >> 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). > > That would work, but it is IMHO too much (interface, not code) > complexity for little gain. In most cases, having a .elc older than > its corresponding .el is a bug (or, let's call it, a temporary > situation), so getting a warning to remind the user about fixing it > seems much more economical. > > That said, sometimes I would've liked to have a hook that runs when a > file is loaded; or the ability to defadvice Fload (you can, except > that Fload is also called from C code, for example for autoloads). > >> 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. :) > > I didn't mean to byte-compile on saving, I meant to byte-compile on > eval-buffer (or whatever method you use to test your code). > >> But that is a hack, so I am now trying to get the root problem >> addressed in the C code where it exists. > > I agree that greater control over the loading process could sometimes > be useful; but I don't think this is a compelling use case. > > Juanma > From monnier@iro.umontreal.ca Mon Feb 2 10:04:17 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 2 Feb 2009 18:04:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.5 required=4.0 tests=FAKE_REPLY_C,HAS_BUG_NUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n12I4BUZ015286 for <2061@emacsbugs.donarmstrong.com>; Mon, 2 Feb 2009 10:04:12 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEACTEhknO+IQk/2dsb2JhbACBbso/hBQGgmw X-IronPort-AV: E=Sophos;i="4.37,366,1231131600"; d="scan'208";a="33211881" Received: from 206-248-132-36.dsl.teksavvy.com (HELO pastel.home) ([206.248.132.36]) by ironport2-out.teksavvy.com with ESMTP; 02 Feb 2009 13:04:06 -0500 Received: by pastel.home (Postfix, from userid 20848) id C15408229; Mon, 2 Feb 2009 13:04:05 -0500 (EST) From: Stefan Monnier To: Juanma Barranquero Cc: 2061@debbugs.gnu.org, Brent Goodrick Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Date: Mon, 26 Jan 2009 19:49:20 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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... A common case for me is "bzr pull" or "cvs update" or "tla star-merge" to bring in new changes. I don't look at all the Elisp files brought in so byte-compile-file is not convenient, and byte-compilation often leads to odd results because the `require's read the old .elc files. Stefan From lekktu@gmail.com Mon Feb 2 10:56:54 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 2 Feb 2009 18:56:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f10.google.com (mail-ew0-f10.google.com [209.85.219.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n12Iuox2029131 for <2061@emacsbugs.donarmstrong.com>; Mon, 2 Feb 2009 10:56:51 -0800 Received: by ewy3 with SMTP id 3so2187952ewy.1 for <2061@emacsbugs.donarmstrong.com>; Mon, 02 Feb 2009 10:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2hBo9JwEg1Sls+CWR0FAudV8U+5OW1xHus+W0RO2cyY=; b=S9B95RMj84hYeMIMtsuPD2XKZ0lYzo0NzmO9diJR7X5z+1H53vt365PFDCWw7ziKL0 z8xy6XCXdeIJphhWdgmn3BEC4FM4Pi00s+3hvLgzGZV62iPD5LKdamGO1nXjJmZmwSu+ KBgIMCXM52aK5W+sYm/9LnA8Iut8WPvdwNX3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WGIwtGD+abEJPhX+nVh33EBGgHuNicvp3LthoCYBfxbK1+Iam4ygplWY3gtByVYHHd G4N0s6u5J0l0Vw8ukpDPIO6z1zT8El+2tnR/LH+2BGixrG79fcAVL4wbm2+b5JYM8uLg HBlIvjep+rFhEeIBoDsFUPFUXt0z2/nCZI00w= MIME-Version: 1.0 Received: by 10.210.34.19 with SMTP id h19mr456099ebh.199.1233601004479; Mon, 02 Feb 2009 10:56:44 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2009 19:56:44 +0100 Message-ID: Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file From: Juanma Barranquero To: Stefan Monnier Cc: 2061@debbugs.gnu.org, Brent Goodrick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Tue, Jan 27, 2009 at 01:49, Stefan Monnier wrote: > A common case for me is "bzr pull" or "cvs update" or "tla star-merge" > to bring in new changes. I don't look at all the Elisp files brought in > so byte-compile-file is not convenient, and byte-compilation often leads > to odd results because the `require's read the old .elc files. I'm used to do "make cvs-update" just about after every "cvs update". Juanma From rms@gnu.org Tue Feb 3 02:01:11 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 3 Feb 2009 10:01:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n13A18fU029083 for <2061@emacsbugs.donarmstrong.com>; Tue, 3 Feb 2009 02:01:09 -0800 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LUI3t-0003qF-2X; Tue, 03 Feb 2009 04:59:21 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Stefan Monnier , 2061@debbugs.gnu.org CC: lekktu@gmail.com, 2061@debbugs.gnu.org, bgoodr@gmail.com In-reply-to: (message from Stefan Monnier on Mon, 26 Jan 2009 19:49:20 -0500) Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Reply-to: rms@gnu.org References: Message-Id: Date: Tue, 03 Feb 2009 04:59:21 -0500 A common case for me is "bzr pull" or "cvs update" or "tla star-merge" to bring in new changes. I don't look at all the Elisp files brought in so byte-compile-file is not convenient, and byte-compilation often leads to odd results because the `require's read the old .elc files. Are you saying that in this case you would want to load the .el files instead? If so, I wonder if the right solution is to do something special when loading a file for `require' in compilation. Perhaps offer to compile them? From monnier@IRO.UMontreal.CA Tue Feb 3 13:07:46 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 3 Feb 2009 21:07:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n13L7ajU003909 for <2061@emacsbugs.donarmstrong.com>; Tue, 3 Feb 2009 13:07:38 -0800 Received: from alfajor.home (vpn-132-204-232-163.acd.umontreal.ca [132.204.232.163]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n13L8E8w030065; Tue, 3 Feb 2009 16:08:14 -0500 Received: by alfajor.home (Postfix, from userid 20848) id 09BC6A22D1; Tue, 3 Feb 2009 16:07:32 -0500 (EST) From: Stefan Monnier To: rms@gnu.org Cc: 2061@debbugs.gnu.org, lekktu@gmail.com, bgoodr@gmail.com Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Message-ID: References: Date: Tue, 03 Feb 2009 16:07:32 -0500 In-Reply-To: (Richard M. Stallman's message of "Tue, 03 Feb 2009 04:59:21 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3203=0 > If so, I wonder if the right solution is to do something special when loading > a file for `require' in compilation. Indeed, that's what I do in my local branch, where the bytecompiler's handling of require gives precedence to the .el files over the .elc files. > Perhaps offer to compile them? It needs to work in batch mode. And byte-compiling them can easily fall into circularities. Stefan From monnier@IRO.UMontreal.CA Tue Feb 3 13:08:52 2009 Received: (at 2061) by emacsbugs.donarmstrong.com; 3 Feb 2009 21:08:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n13L8m5o003931 for <2061@emacsbugs.donarmstrong.com>; Tue, 3 Feb 2009 13:08:50 -0800 Received: from alfajor.home (vpn-132-204-232-163.acd.umontreal.ca [132.204.232.163]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n13L9Sc3030142; Tue, 3 Feb 2009 16:09:28 -0500 Received: by alfajor.home (Postfix, from userid 20848) id 2F91CA22D1; Tue, 3 Feb 2009 16:08:47 -0500 (EST) From: Stefan Monnier To: Juanma Barranquero Cc: 2061@debbugs.gnu.org, Brent Goodrick Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files Message-ID: References: Date: Tue, 03 Feb 2009 16:08:46 -0500 In-Reply-To: (Juanma Barranquero's message of "Mon, 2 Feb 2009 19:56:44 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3203=0 >> A common case for me is "bzr pull" or "cvs update" or "tla star-merge" >> to bring in new changes. I don't look at all the Elisp files brought in >> so byte-compile-file is not convenient, and byte-compilation often leads >> to odd results because the `require's read the old .elc files. > I'm used to do "make cvs-update" just about after every "cvs update". I use revisiton control tools for several Elisp packages outside of Emacs. I don't want to reinvent the same Makefile rules for each one of them. Stefan From rgm@gnu.org Fri Mar 6 12:23:23 2009 Received: (at control) by emacsbugs.donarmstrong.com; 6 Mar 2009 20:23:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-8.0 required=4.0 tests=HAS_BUG_NUMBER, VALID_BTS_CONTROL,X_DEBBUGS_NO_ACK autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n26KNE5M028908; Fri, 6 Mar 2009 12:23:15 -0800 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LfgZd-0000Ip-IB; Fri, 06 Mar 2009 15:23:13 -0500 From: Glenn Morris To: 2577@debbugs.gnu.org Subject: Re: bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer References: <87mybya04l.fsf@hagelb.org> X-Spook: Downing Street Roswell White House ISEC kilo class Ortega X-Ran: K7:GK!3\M*1}$rj2KYs%+O)q(lg^Jg6KBG&VOM2/:RgmbGOZw*L0eU{3`9vZ\Rt~.lhWXG X-Hue: cyan X-Debbugs-No-Ack: yes X-Attribution: GM Date: Fri, 06 Mar 2009 15:23:13 -0500 In-Reply-To: <87mybya04l.fsf@hagelb.org> (Phil Hagelberg's message of "Fri, 06 Mar 2009 12:04:42 -0800") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-CrossAssassin-Score: 2 tags 2577 = forcemerge 2061 2577 stop Phil Hagelberg wrote: > Ideally a flag would exist that could instruct Emacs to ignore > out-of-date .elc files. I understand this is not appropriate to submit > during a feature freeze, but saying it's not a problem is not helpful. Then this is a duplicate of wishlist item #2061. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 18:40:14 2011 Received: (at control) by debbugs.gnu.org; 4 Jun 2011 22:40:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSzVu-00083z-5k for submit@debbugs.gnu.org; Sat, 04 Jun 2011 18:40:14 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSzVt-00083b-16; Sat, 04 Jun 2011 18:40:13 -0400 Received: from localhost ([127.0.0.1]:53594) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSzVl-0006sW-Ku; Sat, 04 Jun 2011 18:40:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19946.46148.665574.788456@fencepost.gnu.org> Date: Sat, 4 Jun 2011 18:40:04 -0400 From: Glenn Morris To: 2577-quiet@debbugs.gnu.org Subject: Re: bug#2577 X-Attribution: GM X-Mailer: VM (www.wonderworks.com/vm), GNU Emacs (www.gnu.org/software/emacs) X-Hue: cyan X-Ran: )4oP=q-XIO:rN5,&Xg3^#Ns]M_&am-u-Kw..)@c:,vLeO4%t6/ETxJql]0>Dg3x=uRggz= X-Debbugs-No-Ack: yes X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) unmerge 2577 stop Actually, this isn't just a dupe of 2061. If there were some variable you could set to prefer loading of .el if newer than .elc, it would not help for the specific case of .emacs, because the setting would have to go... in .emacs. Maybe there could be an environment variable as well. But this probably remains a "wontfix". From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 17 22:24:12 2013 Received: (at 2061-done) by debbugs.gnu.org; 18 Dec 2013 03:24:12 +0000 Received: from localhost ([127.0.0.1]:56380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vt7k4-0001EP-Fk for submit@debbugs.gnu.org; Tue, 17 Dec 2013 22:24:12 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:51263) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vt7k2-0001EI-Qu for 2061-done@debbugs.gnu.org; Tue, 17 Dec 2013 22:24:11 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Vt7k2-00008I-9m; Tue, 17 Dec 2013 22:24:10 -0500 From: Glenn Morris To: 2061-done@debbugs.gnu.org Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files References: X-Spook: MD5 Honduras militia Glock Blowpipe CDMA Bush Wired Al X-Ran: zkjmQ@OAEDt(+\}.7n/'|h|^1"9@Lx4E"Lrpx>d8!{B]9:]xsnxW;iru<-/NAuH]5$."QH X-Hue: blue X-Attribution: GM Date: Tue, 17 Dec 2013 22:24:10 -0500 In-Reply-To: (Stefan Monnier's message of "Tue, 03 Feb 2009 16:08:46 -0500") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: 2061-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.5 (-----) Version: 24.4 Added option `load-prefer-newer'. From unknown Mon Aug 11 12:53:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 15 Jan 2014 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 07:46:36 2014 Received: (at control) by debbugs.gnu.org; 11 Feb 2014 12:46:36 +0000 Received: from localhost ([127.0.0.1]:45998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDCjT-0004sL-Tb for submit@debbugs.gnu.org; Tue, 11 Feb 2014 07:46:36 -0500 Received: from mail-yh0-f51.google.com ([209.85.213.51]:57249) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDCjR-0004s6-Jc for control@debbugs.gnu.org; Tue, 11 Feb 2014 07:46:34 -0500 Received: by mail-yh0-f51.google.com with SMTP id t59so6671217yho.10 for ; Tue, 11 Feb 2014 04:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=uMVU4jWwQU35q55sEG91qLCpsewZi9wix1YVb6aAJWw=; b=hVfKkmumrG3A7Tk9yqNu+QH0csTkg9jPNKnUb6/B8CWOT/jVlYcywwNhhMEVsefw1J ScXNADco7R40JTqqO/MF0/F6h0IAWYDVNLBkQSoEKZ4rwMCxToNhH++BfvkXu2Ym/N+M 6SBzIkN9PZfs9bdshwMocCJguNwJyUAeIcipw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=uMVU4jWwQU35q55sEG91qLCpsewZi9wix1YVb6aAJWw=; b=XhLDv0N9g5hxJ1yZeyVsP7mN8iyKdLynMs1Q937T1f2gX9zaux6I8nCDd69TnEuqcy VzdU8wfeGMCVFRmaxay7Lt7SBnRcs7odzHoe9KqI19PxpJPhe2JkYb41kNZCjhgGg1RQ aTy/cYVHg5CWrFTPFmatS5tUkXQabvPpGnZjAyYAiftoX3X0i3Tru0p0oWfbk4eLEED9 dMTPXqIkNlW8O0aT/ylmgRwhch32DtiQb+JRQjAQB6o02mCuuKpW8Dbjkrg2lZbNpXcB j/ek3iKG3cl6vbTGbAGxw6VjwUSC29HvVGk3mEQWZxWlqvZi8zOPxrJLi2ngL+oLdgpz Lsow== X-Gm-Message-State: ALoCoQlhnwuUGvo7oA/gVjSJxZTCQVvECC1XD8VXy09dPPGnYBLf6y3FbankSCi8S0FqebM57+SI MIME-Version: 1.0 X-Received: by 10.236.88.179 with SMTP id a39mr1765798yhf.83.1392122787901; Tue, 11 Feb 2014 04:46:27 -0800 (PST) Received: by 10.170.41.208 with HTTP; Tue, 11 Feb 2014 04:46:27 -0800 (PST) Date: Tue, 11 Feb 2014 12:46:27 +0000 Message-ID: Subject: From: Reuben Thomas To: control@debbugs.gnu.org Content-Type: multipart/alternative; boundary=14dae9d2fb3441c95404f220d82c X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 2061 unarchive 2061 [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.213.51 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 2.0 BLANK_SUBJECT Subject is present but empty 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 TVD_SPACE_RATIO TVD_SPACE_RATIO 0.2 BODY_URI_ONLY Message body is only a URI in one line of text or for an image X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 2061 unarchive 2061 [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.213.51 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 2.0 BLANK_SUBJECT Subject is present but empty 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 TVD_SPACE_RATIO TVD_SPACE_RATIO 0.2 BODY_URI_ONLY Message body is only a URI in one line of text or for an image --14dae9d2fb3441c95404f220d82c Content-Type: text/plain; charset=ISO-8859-1 unarchive 2061 --14dae9d2fb3441c95404f220d82c Content-Type: text/html; charset=ISO-8859-1
unarchive 2061
--14dae9d2fb3441c95404f220d82c-- From unknown Mon Aug 11 12:53:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug No longer marked as fixed in versions 24.4 and reopened. Date: Tue, 11 Feb 2014 12:47:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug No longer marked as fixed in versions 24.4 and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 07:48:51 2014 Received: (at 2061) by debbugs.gnu.org; 11 Feb 2014 12:48:51 +0000 Received: from localhost ([127.0.0.1]:46009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDCle-0004wN-PS for submit@debbugs.gnu.org; Tue, 11 Feb 2014 07:48:51 -0500 Received: from mail-yk0-f176.google.com ([209.85.160.176]:59813) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDClc-0004wA-NS for 2061@debbugs.gnu.org; Tue, 11 Feb 2014 07:48:49 -0500 Received: by mail-yk0-f176.google.com with SMTP id 19so10914151ykq.7 for <2061@debbugs.gnu.org>; Tue, 11 Feb 2014 04:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zLpkNkuDERwyUySii+fCIKO7KeTs4sfhls+Tez5/muo=; b=bKNt5jt9IObaP8ZWoNBVlIbWYC+x7NLFpSrq0hv2I+SLKR+Ymlf5XUShiSSEy2aZBn O4Zv/6kTG+4SmOAW1T48oRGB6RnrSJBXw5fUccv4MY3fhjsp62DFyvMRtRhnQRcz2P1l +cSdi0+HVGOG2UT0sxzefp3qJKl+cmjTnoMW8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zLpkNkuDERwyUySii+fCIKO7KeTs4sfhls+Tez5/muo=; b=JluJazOazytHcNJsbQSW1dIweL+QYx3OQUWfggEL5xWucvChZie/hvmelpzXv2eyin KMFKJ33VsFOUToYPfEzLe49uwaV66EPuv4C8pEm2xvKWz4EVcAzE8UeE4vbqLP6l4wYS vdZZkQ3LhKL2vHXdxX08tmj6z5G7hsvQtRO0DHIh4/CEZL+9Huv51uAqRPVhZfgO9XQ4 UE8pfr6eOtj0YVyUr7fekMj92dK2b16nppki3nbk/wfRXE54d0zA++oabxjrsySEZksz dXrGPsqJADeyRRjEI3Bnjj/YN9tQQqigEKXrF6COhM+BNccDiaR+J1beglLL09KFXdT4 ogfg== X-Gm-Message-State: ALoCoQnfG5N5SfD5/fztRaX/FY8mkiqm9rhns/oI7dYGnqdsbc0OwwLvEmTglA8Gx1sElJwwxumT MIME-Version: 1.0 X-Received: by 10.236.122.99 with SMTP id s63mr23453429yhh.19.1392122923005; Tue, 11 Feb 2014 04:48:43 -0800 (PST) Received: by 10.170.41.208 with HTTP; Tue, 11 Feb 2014 04:48:42 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Feb 2014 12:48:42 +0000 Message-ID: Subject: Fwd: Loading .el when newer than .elc From: Reuben Thomas To: 2061@debbugs.gnu.org Content-Type: multipart/alternative; boundary=20cf301af3354f582204f220e0f6 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2061 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --20cf301af3354f582204f220e0f6 Content-Type: text/plain; charset=ISO-8859-1 I just got annoyed enough about missing a warning that an .el file is newer than an .elc file to want to file a bug report, and sure enough found this issue has already been discussed. To summarize the discussion so far, the following reasons have been advanced for not wanting automatically to prefer a newer .el over an older .elc: 1. One might be working on the .el file, and not want to load it yet. 2. This is a bug, which should be fixed by recompiling the .el. Several workarounds have been proposed for those who want to use the newest version of the .el; they all involve recompiling the file (which some people complained slowed things down too much, and others pointed out could lead to loops when working on a large project), and all involve taking action for specific files, e.g. per-project, or per-file, or per-directory. I think it's worth looking at those objections again in a modern context: 1. We don't work on deployed code any more (or shouldn't!). We use version control systems, we run tests before deploying. When I fiddle with a file, I always want my changes to take effect instantly: either I'm working on code I'm developing, or I'm trying a fix on a deployed file (and am willing to keep the bits if it breaks!). 2. GNU distributions go to some lengths to ensure that all system-installed .el files are compiled and up-to-date. el-get does the same for user-installed packages. There's little else. Meanwhile, the workarounds require almost as much effort to install and maintain as simply remembering to byte-compile everything. Personally, I have wasted hours by thinking I'm loading a new .el when I'm loading an old .elc, plus going through various recompilation dances when I do remember. The time that defaulting to .elc has saved me is minimal, owing to Debian+el-get taking care of recompilation. Hence, could we have a preference that reverses the behavior, i.e. when the .el is newer, it is loaded, and a warning emitted? The default behavior should of course remain the same. It's a simple, uniform, discoverable solution. I'd happily work up a patch myself. The preference could be used in .dir-locals.el by users who preferred to switch it on only for, say, per-user site-lisp directories or project directories. How about: load-el-when-newer (defaults to nil) ? -- http://rrt.sc3d.org --20cf301af3354f582204f220e0f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I just got annoyed enough about missing a warning that an = .el file is newer than an .elc file to want to file a bug report, and sure = enough found this issue has already been discussed.

To summarize the= discussion so far, the following reasons have been advanced for not wantin= g automatically to prefer a newer .el over an older .elc:

1. One might be working on the .el file, and not want to load it yet.
2. This is a bug, which should be fixed by recompiling the .el.
Several workarounds have been proposed for those who want to use the newe= st version of the .el; they all involve recompiling the file (which some pe= ople complained slowed things down too much, and others pointed out could l= ead to loops when working on a large project), and all involve taking actio= n for specific files, e.g. per-project, or per-file, or per-directory.

I think it's worth looking at those objections again in a modern co= ntext:

1. We don't work on deployed code any more (or shouldn= 9;t!). We use version control systems, we run tests before deploying. When = I fiddle with a file, I always want my changes to take effect instantly: ei= ther I'm working on code I'm developing, or I'm trying a fix on= a deployed file (and am willing to keep the bits if it breaks!).

2. GNU distributions go to some lengths to ensure that all system-insta= lled .el files are compiled and up-to-date. el-get does the same for user-i= nstalled packages. There's little else.

Meanwhile, the workaroun= ds require almost as much effort to install and maintain as simply remember= ing to byte-compile everything.

Personally, I have wasted hours by thinking I'm loading a new .el w= hen I'm loading an old .elc, plus going through various recompilation d= ances when I do remember. The time that defaulting to .elc has saved me is = minimal, owing to Debian+el-get taking care of recompilation.

Hence, could we have a preference that reverses the behavior, i.e. when= the .el is newer, it is loaded, and a warning emitted? The default behavio= r should of course remain the same. It's a simple, uniform, discoverabl= e solution. I'd happily work up a patch myself. The preference could be= used in .dir-locals.el by users who preferred to switch it on only for, sa= y, per-user site-lisp directories or project directories.

How about: load-el-when-newer (defaults to nil) ?

--
http://rrt.sc3d.org
--20cf301af3354f582204f220e0f6-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 11:14:54 2014 Received: (at 2061) by debbugs.gnu.org; 11 Feb 2014 16:14:54 +0000 Received: from localhost ([127.0.0.1]:47620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDFz3-00063w-Iz for submit@debbugs.gnu.org; Tue, 11 Feb 2014 11:14:54 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:43543) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDFz0-00063b-Db for 2061@debbugs.gnu.org; Tue, 11 Feb 2014 11:14:51 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N0U00A00A3QEJ00@a-mtaout21.012.net.il> for 2061@debbugs.gnu.org; Tue, 11 Feb 2014 18:14:43 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0U00AIAAGJ0Y80@a-mtaout21.012.net.il>; Tue, 11 Feb 2014 18:14:43 +0200 (IST) Date: Tue, 11 Feb 2014 18:14:31 +0200 From: Eli Zaretskii Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc In-reply-to: X-012-Sender: halo1@inter.net.il To: Reuben Thomas Message-id: <838uthtymw.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 2061 Cc: 2061@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 11 Feb 2014 12:48:42 +0000 > From: Reuben Thomas > > How about: load-el-when-newer (defaults to nil) ? >From etc/NEWS: ** New option `load-prefer-newer' affects how the `load' function chooses the file to load. If this is non-nil, then when both .el and .elc versions of a file exist, and the caller did not explicitly specify which one to load, then the newer file is loaded. The default, nil, means to always load the .elc file. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 11:37:39 2014 Received: (at 2061) by debbugs.gnu.org; 11 Feb 2014 16:37:39 +0000 Received: from localhost ([127.0.0.1]:47641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGL3-0006kV-Vr for submit@debbugs.gnu.org; Tue, 11 Feb 2014 11:37:38 -0500 Received: from mail-yh0-f53.google.com ([209.85.213.53]:39399) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGL1-0006k5-9d for 2061@debbugs.gnu.org; Tue, 11 Feb 2014 11:37:36 -0500 Received: by mail-yh0-f53.google.com with SMTP id v1so6969388yhn.40 for <2061@debbugs.gnu.org>; Tue, 11 Feb 2014 08:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=If0RAbeQ10idScZWOXE8aAIKVqeRs11MEqTRkJVg6y8=; b=yOkZpURcCZs0zaDk6UoxstAPxo8vY4x/YrjXjLKXR3H5lGElemroVQ3PxWD98v4LHM KkF6XvkaV+9MuTAKg6EyOgMaWf9RpHtqlaOSJWe5qpLpMHofuypYrPNpI/U1wbY93h0E vvFPVkKR+QFYkH7ivAnV5m6FXUDJ/1BBX0QUk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=If0RAbeQ10idScZWOXE8aAIKVqeRs11MEqTRkJVg6y8=; b=GDJm3/v+NFxj+yAUk24zWyoRdf9Y4fm5Zi9GA8KsH8FjmwlhL0vf1KMdMVj6yIYfIi qNrhDWY4Sjh33iv/24pB9Eez4ackWrrDe/Q8IXh3n2wn4hRR22hfnr/VyFeoPl7v+9Au 1iyKUzpvv7L4RDU7BsyGenrplYk73esFlsiYbmFy+QZ50bcHeZPsX6jQQRU3av4ajMe4 ANnoou5fTJriw9HdC6C636v1RziZfOnks/K8qhCggNq/6pWBMgfXzokyH3KEp4PiqUzC Fkup/QqlWYyL0i+I+orCPKZX2rckJix6OGLY5xNBc6XES9JOZxdXSY4Wr/FgaXzx55bH atbg== X-Gm-Message-State: ALoCoQmXlDyR5hDteo6TznwgkfvX/Wjcj8iSq6kRvAaudT2FQSEgUEBqzc+ycrHj9Wk+rK1wcEFq MIME-Version: 1.0 X-Received: by 10.236.222.231 with SMTP id t97mr1762374yhp.125.1392136649489; Tue, 11 Feb 2014 08:37:29 -0800 (PST) Received: by 10.170.41.208 with HTTP; Tue, 11 Feb 2014 08:37:29 -0800 (PST) In-Reply-To: <838uthtymw.fsf@gnu.org> References: <838uthtymw.fsf@gnu.org> Date: Tue, 11 Feb 2014 16:37:29 +0000 Message-ID: Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc From: Reuben Thomas To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c2009e79197004f2241275 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2061 Cc: 2061@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c2009e79197004f2241275 Content-Type: text/plain; charset=ISO-8859-1 On 11 February 2014 16:14, Eli Zaretskii wrote: > > Date: Tue, 11 Feb 2014 12:48:42 +0000 > > From: Reuben Thomas > > > > How about: load-el-when-newer (defaults to nil) ? > > From etc/NEWS: > > ** New option `load-prefer-newer' affects how the `load' function chooses > the file to load. If this is non-nil, then when both .el and .elc > versions of a file exist, and the caller did not explicitly specify > which one to load, then the newer file is loaded. The default, nil, > means to always load the .elc file. > Joy! I'm sorry my timing was bad, in that I looked into this after it had been committed, but before it had been released. Thanks for the intelligence. -- http://rrt.sc3d.org --001a11c2009e79197004f2241275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c2009e79197004f2241275-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 11:49:42 2014 Received: (at control) by debbugs.gnu.org; 11 Feb 2014 16:49:42 +0000 Received: from localhost ([127.0.0.1]:47676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGWj-00077y-7m for submit@debbugs.gnu.org; Tue, 11 Feb 2014 11:49:41 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:46519 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGWg-00077k-Uj for control@debbugs.gnu.org; Tue, 11 Feb 2014 11:49:39 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WDGWg-0008Sh-EP for control@debbugs.gnu.org; Tue, 11 Feb 2014 11:49:38 -0500 Date: Tue, 11 Feb 2014 11:49:38 -0500 Message-Id: Subject: control message for bug 2061 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) close 2061 24.4 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 12:03:32 2014 Received: (at 2061) by debbugs.gnu.org; 11 Feb 2014 17:03:32 +0000 Received: from localhost ([127.0.0.1]:47704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGk7-0000Ga-5h for submit@debbugs.gnu.org; Tue, 11 Feb 2014 12:03:32 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:47053 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGk4-0000GK-0R for 2061@debbugs.gnu.org; Tue, 11 Feb 2014 12:03:28 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WDGk1-00055F-LS; Tue, 11 Feb 2014 12:03:25 -0500 From: Glenn Morris To: Reuben Thomas Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc References: <838uthtymw.fsf@gnu.org> X-Spook: Skipjack dictionary MP5K-SD high security top secret X-Ran: 4,,8LiWX5Zw"5k*>\vYMr-;+FyC(<2ycx@hX&(Kpw0fq,IT]g!j.?1H[lZ%WQ6/SpI-Ll7 X-Hue: green X-Debbugs-No-Ack: yes X-Attribution: GM Date: Tue, 11 Feb 2014 12:03:25 -0500 In-Reply-To: (Reuben Thomas's message of "Tue, 11 Feb 2014 16:37:29 +0000") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 (----) X-Debbugs-Envelope-To: 2061 Cc: Eli Zaretskii , 2061@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.9 (----) Reuben Thomas wrote: > Joy! I'm sorry my timing was bad, in that I looked into this after it had > been committed, but before it had been released. That's fine, but why not read the report, especially the close message, before reopening it? http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2061#106 seems clear to me. Now the OP will wonder why his bug was opened and closed again. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 12:15:35 2014 Received: (at 2061) by debbugs.gnu.org; 11 Feb 2014 17:15:35 +0000 Received: from localhost ([127.0.0.1]:47724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGvm-0000eB-VG for submit@debbugs.gnu.org; Tue, 11 Feb 2014 12:15:35 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:42509) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGvk-0000ds-5j for 2061@debbugs.gnu.org; Tue, 11 Feb 2014 12:15:33 -0500 Received: by mail-yk0-f174.google.com with SMTP id 20so11881438yks.5 for <2061@debbugs.gnu.org>; Tue, 11 Feb 2014 09:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MV/HbISfwzsirvWcx8P2uOvBudN04+PlnZZa1ERRxSM=; b=g1JWl5hA9N1jtOIxU96HFWXnRD6UbGB3ZykvUoX8aQeNDtmpLdtilgNLtP5pMpLqKR dpqahpc3/sU7H0AVWwZMutnRvajdxiYXhpiFpk3ZIRKWg6vC/eqN9bL1n+9TFiBQG2jb dS8W9rU+UXPbu4Tnnh6QuqpLKBwqIaeFZHGgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MV/HbISfwzsirvWcx8P2uOvBudN04+PlnZZa1ERRxSM=; b=I0EIN7n5dX7qTOlCk7rAfc7Tx2s15AznufkDVx00EcQGYWqv4SWLinvi/5p+L3yfcu trG9/HvxwWsjLf8R0mPu0bUEGvI/UYoZ3yls8g3JkFWSHmkHtcjazdowYzFrffcd0Wyl WqbZygKp5LKjLipFQbYlorUUNhEdruSyZZNGbkxT/yM+GkD1E1naxs7GwHYTJpU4sIQG 28OpKGeOGVtWVvurNLcmYySkKjOJ0CN9o7yiMfBfl4mswb+LIXZ0nNKoj5HL+9810dZh KUzlDx08/O/QqiDXTSc9aFI9ZY5VBbbcEcP01YHf3WVtkMdgnfJIOHRp5KtJGYkwRL3d cX9g== X-Gm-Message-State: ALoCoQlIwMESiQ2fsOkgWi1bCTRHu5hpB2CurGCETvaz2iwOiq9wcfZiDbkFk8bLPGdjsZlF/pgr MIME-Version: 1.0 X-Received: by 10.236.81.237 with SMTP id m73mr35344792yhe.29.1392138926417; Tue, 11 Feb 2014 09:15:26 -0800 (PST) Received: by 10.170.41.208 with HTTP; Tue, 11 Feb 2014 09:15:26 -0800 (PST) In-Reply-To: References: <838uthtymw.fsf@gnu.org> Date: Tue, 11 Feb 2014 17:15:26 +0000 Message-ID: Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc From: Reuben Thomas To: Glenn Morris Content-Type: multipart/alternative; boundary=20cf3011dba93000aa04f2249a85 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2061 Cc: Eli Zaretskii , 2061@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --20cf3011dba93000aa04f2249a85 Content-Type: text/plain; charset=ISO-8859-1 On 11 February 2014 17:03, Glenn Morris wrote: > Reuben Thomas wrote: > > > Joy! I'm sorry my timing was bad, in that I looked into this after it had > > been committed, but before it had been released. > > That's fine, but why not read the report, especially the close message, > before reopening it? > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2061#106 > > seems clear to me. > You're right, it is. However, I read the bug report on the mailing list archive, and didn't find the close message there. The moral is to use the debbugs interface for completeness. -- http://rrt.sc3d.org --20cf3011dba93000aa04f2249a85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 1= 1 February 2014 17:03, Glenn Morris <rgm@gnu.org> wrote:
Reuben Thomas wrote:

> Joy! I'm sorry my timing was bad, in that I looked into this after= it had
> been committed, but before it had been released.

That's fine, but why not read the report, especially the close me= ssage,
before reopening it?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D2061#106

seems clear to me.

You're right, it= is. However, I read the bug report on the mailing list archive, and didn&#= 39;t find the close message there. The moral is to use the debbugs interfac= e for completeness.

--
http://rrt.sc3d.org<= /a>
--20cf3011dba93000aa04f2249a85-- From unknown Mon Aug 11 12:53:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 12 Mar 2014 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator