bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Paul Pogonyshev-2
After (byte-compile-file "..." t) one normally expects that the file
is loaded, all its functions and variables are visible etc.  However,
if file contains local variable `no-byte-compile', not only
compilation is cancelled, `byte-compile-file' also doesn't load the
file.

Expected: if `byte-compile-file' cancels byte-compilation and `load'
is non-nil, it should load the uncompiled source instead.

Paul



Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Eli Zaretskii
> From: Stefan Kangas <[hidden email]>
> Date: Sat, 5 Sep 2020 00:30:38 +0000
> Cc: [hidden email]
>
>     Compile a file of Lisp code named FILENAME into a file of byte code.
>     The output file’s name is generated by passing FILENAME to the
>     function ‘byte-compile-dest-file’ (which see).
>     With prefix arg (noninteractively: 2nd arg), LOAD the file after compiling.
>                                                                ^^^^^^^^^^^^^^^
>
> So should we load the file if we did not compile the file?  I'm thinking
> yes, and I don't see what it could hurt to change it to load the file.
> If the user uses a prefix arg or the LOAD argument from Lisp, surely
> that was the intention.
>
> But on the other hand the text above seems deliberate, somehow?  (And
> AFAICT the behavior has been not to load the file since pretty much
> forever, possibly since byte-compilation was first added.)

I'm indeed bothered by backward incompatibility of such a change.
Paul expected the file to be loaded unconditionally, but how do we
know someone else isn't expecting the opposite in this case?  Also, do
we want the same behavior in the interactive case?

At the very least, if we decide to install this, the change in
behavior should be in NEWS.

Stefan, any comments on this?



Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Stefan Monnier
>>     Compile a file of Lisp code named FILENAME into a file of byte code.
>>     The output file’s name is generated by passing FILENAME to the
>>     function ‘byte-compile-dest-file’ (which see).
>>     With prefix arg (noninteractively: 2nd arg), LOAD the file after compiling.
>>                                                                ^^^^^^^^^^^^^^^
>>
>> So should we load the file if we did not compile the file?  I'm thinking
>> yes, and I don't see what it could hurt to change it to load the file.
>> If the user uses a prefix arg or the LOAD argument from Lisp, surely
>> that was the intention.
>>
>> But on the other hand the text above seems deliberate, somehow?  (And
>> AFAICT the behavior has been not to load the file since pretty much
>> forever, possibly since byte-compilation was first added.)
>
> I'm indeed bothered by backward incompatibility of such a change.
> Paul expected the file to be loaded unconditionally, but how do we
> know someone else isn't expecting the opposite in this case?  Also, do
> we want the same behavior in the interactive case?
>
> At the very least, if we decide to install this, the change in
> behavior should be in NEWS.
>
> Stefan, any comments on this?

FWIW, I find the "and load" feature to be a mistake: the function should
return whether or not it successfully compiled the file, but shouldn't
offer to load the result, since the callers can just as easily do
it themselves (and then they can easily control what happens when
compilation did not succeed).
So, I'd suggest we deprecate that "feature" rather than try and decide
which behavior is better.


        Stefan




Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Stefan Kangas
Stefan Monnier <[hidden email]> writes:

> FWIW, I find the "and load" feature to be a mistake: the function should
> return whether or not it successfully compiled the file, but shouldn't
> offer to load the result, since the callers can just as easily do
> it themselves (and then they can easily control what happens when
> compilation did not succeed).
> So, I'd suggest we deprecate that "feature" rather than try and decide
> which behavior is better.

It's pretty convenient when running interactively though.  I've tried
using `C-u M-x byte-compile-file' (instead of my usual eval-buffer) for
the last couple of days, and I kind of like getting both
byte-compilation and load-file in one command.

But if we do deprecate this, is there a better alternative that we can
point users to?  Should we just tell them to run two commands?



Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Emacs - Bugs mailing list
Stefan Kangas <[hidden email]> writes:

> Stefan Monnier <[hidden email]> writes:
>
>> FWIW, I find the "and load" feature to be a mistake: the function should
>> return whether or not it successfully compiled the file, but shouldn't
>> offer to load the result, since the callers can just as easily do
>> it themselves (and then they can easily control what happens when
>> compilation did not succeed).
>> So, I'd suggest we deprecate that "feature" rather than try and decide
>> which behavior is better.
>
> It's pretty convenient when running interactively though.  I've tried
> using `C-u M-x byte-compile-file' (instead of my usual eval-buffer) for
> the last couple of days, and I kind of like getting both
> byte-compilation and load-file in one command.
>
> But if we do deprecate this, is there a better alternative that we can
> point users to?  Should we just tell them to run two commands?

Hi Stefan,

would having the load performed by `emacs-lisp-byte-compile-and-load' an
option?

Ciao

  Andrea



Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Stefan Kangas
Andrea Corallo <[hidden email]> writes:

>>> FWIW, I find the "and load" feature to be a mistake: the function should
>>> return whether or not it successfully compiled the file, but shouldn't
>>> offer to load the result, since the callers can just as easily do
>>> it themselves (and then they can easily control what happens when
>>> compilation did not succeed).
>>> So, I'd suggest we deprecate that "feature" rather than try and decide
>>> which behavior is better.
>>
>> But if we do deprecate this, is there a better alternative that we can
>> point users to?  Should we just tell them to run two commands?
>
> would having the load performed by `emacs-lisp-byte-compile-and-load' an
> option?

Yes, that is good.  I didn't know about that command.

So I agree with Stefan M that the prefix argument should be deprecated.
Do we have a process for that or should it just be removed?



Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Eli Zaretskii
> From: Stefan Kangas <[hidden email]>
> Date: Sun, 13 Sep 2020 06:06:30 -0700
> Cc: Stefan Monnier <[hidden email]>, Eli Zaretskii <[hidden email]>, [hidden email],
> [hidden email]
>
> So I agree with Stefan M that the prefix argument should be deprecated.
> Do we have a process for that or should it just be removed?

We cannot just remove it.  We should document that it's deprecated and
use advertised-calling-convention to advertise the signature without
it (which will also produce a warning about using the argument in some
situations).



Reply | Threaded
Open this post in threaded view
|

bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter

Stefan Kangas
Eli Zaretskii <[hidden email]> writes:

>> So I agree with Stefan M that the prefix argument should be deprecated.
>> Do we have a process for that or should it just be removed?
>
> We cannot just remove it.  We should document that it's deprecated and
> use advertised-calling-convention to advertise the signature without
> it (which will also produce a warning about using the argument in some
> situations).

How about the attached patch?

0001-byte-compile-file-Make-optional-LOAD-argument-obsole.patch (10K) Download Attachment