bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Alex]

Following on from discussion at:

http://curiousprogrammer.wordpress.com/2009/03/04/compiling-at-emacs-startup

I humbly submit the following bug report:

From:  <alex@bennee.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer
--text follows this line--

Currently startup.el warns if .emacs.elc is newer than .emacs however
this hides subtle bugs if people don't carefully watch their logs/mode
line during startup. Although many people have clever auto-compile
magic every tiome they save .emacs this often break down when they
pull in updates via SCMs.

It should still warn, but by default it should go with the newest
version.

-- 
Alex, homepage: http://www.bennee.com/~alex/
It is far better to be deceived than to be undeceived by those we love.

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Stefan Monnier]

> Currently startup.el warns if .emacs.elc is newer than .emacs however
> this hides subtle bugs if people don't carefully watch their logs/mode
> line during startup. Although many people have clever auto-compile
> magic every tiome they save .emacs this often break down when they
> pull in updates via SCMs.

I think that if people compile their .emacs they get what they ask for.


        Stefan

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Alex]

On Thu, Mar 05, 2009 at 11:49:42AM -0500, Stefan Monnier wrote:
> > Currently startup.el warns if .emacs.elc is newer than .emacs however
> > this hides subtle bugs if people don't carefully watch their logs/mode
> > line during startup. Although many people have clever auto-compile
> > magic every tiome they save .emacs this often break down when they
> > pull in updates via SCMs.
> 
> I think that if people compile their .emacs they get what they ask for.

That's not very helpful. Emacs obviously supports compiles .emacs as
it has code to deal with it. The code also spots the failure case but
only emits a warning. All I'm arguing is the warning is insufficient
and a cleaner solution is needed. If that solution is to remove
compiled .emacs support then so be it.

I think it is possible for a compiled .emacs to know if it is running
the compiled code and redo the test that starup.el does and act
accordingly so workarounds ar probably possible. But workarounds still
indicate bugs IMHO.

-- 
Alex, homepage: http://www.bennee.com/~alex/
People usually get what's coming to them ... unless it's been mailed.

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Eli Zaretskii]

> Date: Fri, 6 Mar 2009 11:18:54 +0100
> From: Alex <alex@bennee.com>
> Cc: emacs-pretest-bug@gnu.org, 2577@emacsbugs.donarmstrong.com
> 
> On Thu, Mar 05, 2009 at 11:49:42AM -0500, Stefan Monnier wrote:
> > > Currently startup.el warns if .emacs.elc is newer than .emacs however
> > > this hides subtle bugs if people don't carefully watch their logs/mode
> > > line during startup. Although many people have clever auto-compile
> > > magic every tiome they save .emacs this often break down when they
> > > pull in updates via SCMs.
> > 
> > I think that if people compile their .emacs they get what they ask for.
> 
> That's not very helpful.

Maybe not, but it isn't clear, at least not to me, what alternative
behavior do you suggest.  How about spelling it out?

If this is your suggestion:

> It should still warn, but by default it should go with the newest
> version.

then I doubt that it will fly, as Emacs does not do this with any
other Lisp file.  It always warns and goes with the .elc file.

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Jason Rumney]

Alex wrote:
>> I think that if people compile their .emacs they get what they ask for.
>>     
>
> That's not very helpful.

For you, perhaps not. But we have discussed this on emacs-devel numerous 
times in the past, and every time it has been clear that different 
people have different opinions. Many people consider lisp source to be 
"work in progress" until they compile it, and do not want Emacs to load 
it by default if there is a compiled version around. The compromise is 
to issue a warning.

If you have a problem remembering to compile your .emacs, then either 
delete the .emacs.elc file and stop compiling it, or investigate one of 
the solutions that people have come up with to compile it automatically.

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Phil Hagelberg]

The specific failure is this:

A user keeps his entire .emacs.d in an SCM system. This includes not
only his personal customizations, (which would hardly benefit from
compilation) but third-party libraries that haven't made it into Emacs
proper yet. These third-party libraries are byte-compiled in every
checkout of the user's .emacs.d, which span multiple machines.

One of these libraries gets a bug fixed, so he installs the update and
checks it in. Now he moves to another machine that has his dotfiles
checked out, and he pulls in the update, but it's ignored in favour of
the out-of-date .elc file.

Everyone I know who uses Emacs seriously keeps their .emacs.d in an SCM
as well as third-party libraries, so I don't consider this much of an
edge case.

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.

-Phil

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Glenn Morris]

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.

Processed: Re: bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> tags 2577 =
bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer
Tags were: wontfix
Tags set to: 

> forcemerge 2061 2577
bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file
bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer
Forcibly Merged 2061 2577.

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Leo]

On 2009-03-06 20:04 +0000, Phil Hagelberg wrote:
> One of these libraries gets a bug fixed, so he installs the update and
> checks it in. Now he moves to another machine that has his dotfiles
> checked out, and he pulls in the update, but it's ignored in favour of
> the out-of-date .elc file.

Personally, I quite like the current behaviour. As mentioned in another
post, it gives users the power to compile .el files when they are mature
and continue working on them.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Alex]

On Fri, Mar 06, 2009 at 09:37:53PM +0800, Jason Rumney wrote:
> Alex wrote:
>>> I think that if people compile their .emacs they get what they ask for.
>>>     
>>
>> That's not very helpful.
>
> For you, perhaps not. But we have discussed this on emacs-devel numerous  
> times in the past, and every time it has been clear that different  
> people have different opinions. Many people consider lisp source to be  
> "work in progress" until they compile it, and do not want Emacs to load  
> it by default if there is a compiled version around. The compromise is  
> to issue a warning.
>
> If you have a problem remembering to compile your .emacs, then either  
> delete the .emacs.elc file and stop compiling it, or investigate one of  
> the solutions that people have come up with to compile it
automatically.

Typically it's pulling in a later version from an SCM that the warning
case trips up on, as the doesn't trip the compile-on-save hook that
most people use to auto compile .emacs.

As Emacs is a configurable editor would adding a variable to control
this behaviour be the way forward? A lot of people do run their
configs out of an SCM these days. Someone else suggested maybe being
able to use def advice to modify the behaviour which might make any
work-arounds less hacky but I'm not sure what this would entail for
the core code.

-- 
Alex, homepage: http://www.bennee.com/~alex/
Tax and title extra.

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Stefan Monnier]

> Typically it's pulling in a later version from an SCM that the warning
> case trips up on, as the doesn't trip the compile-on-save hook that
> most people use to auto compile .emacs.

People waste more time dealing with problems introduced by compiling
their .emacs than they win by have the file load more quickly.

> As Emacs is a configurable editor would adding a variable to control
> this behaviour be the way forward? A lot of people do run their

Since Emacs is configurable, you can do that in your .emacs actually:
check whether the .el is more recent and load it explicitly if so.


        Stefan

bug#2577: 23.0.91; startup.el should choose .emacs ahead of .emacs.elc if .emacs is newer

[Lennart Borgman]

On Sun, Mar 8, 2009 at 12:11 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Typically it's pulling in a later version from an SCM that the warning
>> case trips up on, as the doesn't trip the compile-on-save hook that
>> most people use to auto compile .emacs.
>
> People waste more time dealing with problems introduced by compiling
> their .emacs than they win by have the file load more quickly.
>
>> As Emacs is a configurable editor would adding a variable to control
>> this behaviour be the way forward? A lot of people do run their
>
> Since Emacs is configurable, you can do that in your .emacs actually:
> check whether the .el is more recent and load it explicitly if so.

It is easier to do this if you divide .emacs in one part that just
load another file that contains what you now have in your .emacs.