From: Brent Goodrick <bgoodr@gmail.com>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: 2061@emacsbugs.donarmstrong.com, Brent Goodrick <bgoodr@gmail.com>
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 [thread overview]
Message-ID: <18815.11809.968195.804775@hungover.brentg.com> (raw)
In-Reply-To: <f7ccd24b0901260045m6ae2a421hbb9abb60366afed8@mail.gmail.com>
Juanma Barranquero writes:
> On Mon, Jan 26, 2009 at 03:19, Brent Goodrick <bgoodr@gmail.com> 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
next prev parent reply other threads:[~2009-01-27 15:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 2:19 bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file Brent Goodrick
2009-01-26 4:08 ` Eli Zaretskii
2009-01-27 15:08 ` Brent Goodrick
2009-01-26 8:45 ` Juanma Barranquero
2009-01-27 15:54 ` Brent Goodrick [this message]
2009-01-28 2:06 ` Juanma Barranquero
2009-01-28 8:29 ` Kevin Rodgers
2009-02-02 16:07 ` Brent Goodrick
2009-01-26 16:31 ` Richard M Stallman
2009-01-27 15:56 ` Brent Goodrick
-- strict thread matches above, loose matches on Subject: below --
2009-01-27 0:49 Stefan Monnier
2009-02-02 18:56 ` Juanma Barranquero
2009-02-03 9:59 ` Richard M Stallman
2009-02-03 21:07 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18815.11809.968195.804775@hungover.brentg.com \
--to=bgoodr@gmail.com \
--cc=2061@emacsbugs.donarmstrong.com \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.