bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file

[Brent Goodrick]

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