[issue]: file.el compiles to null file.elc

[Stephen J. Turnbull]

Aidan Kehoe writes:
 > 
 >  Ar an naoiú lá de mí Méan Fómhair, scríobh Alan Mackenzie: 
 > 
 >  > I'm most impressed (though I haven't tried it out, yet).  Any chance of
 >  > some explanation?  I don't think there's anything invalid about a naked
 >  > `set-buffer', is there?

No, but you need to remember that it potentially has a very long
lifetime unless you explicitly restrict it with save-excursion.  In
general editing, it's not permanent, since command execution
implicitly does a save-excursion.  But in byte-compilation it might as
well be, since only one "command" is executed.
-------------- next part --------------

 > In general, there?s no particular problem with it, but you?re interfering
 > with the guts of byte-compilation in cc-defs.el, we don?t (and can?t really)
 > guarantee that functions with side effects like #'set-buffer won?t cause
 > problems if those side effects aren?t wrapped, when you do something like
 > that.

On the other hand, both buffers are killed within that expression.
Normally you would expect that this would have the effect of returning
to the buffer that was current before the first set-buffer, no?  Is
there perhaps a bug here, or is this something you would not be very
surprised by because of the unusual environment of byte-compilation?

I agree that we probably can't prevent all side effects from
interfering with byte-compilation, but I would think that a
restriction on set-buffer having effects past the return of `load'
during byte-compilation would be reasonable.

Especially if that's GNU-compatible.  WDYT?