emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : emacs-28 windows binaries available from alpha


From: Eli Zaretskii
Subject: Re: [External] : emacs-28 windows binaries available from alpha
Date: Sat, 05 Feb 2022 11:40:52 +0200

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: Drew Adams <drew.adams@oracle.com>,  Andrea Corallo <akrl@sdf.org>,
>   corwin@bru.st,  emacs-devel@gnu.org
> Date: Sat, 05 Feb 2022 10:22:26 +0100
> 
> On a Windows system WITH ligccjit I could load Drew's .elc file without
> an error.
> 
> Then I added his .el file in the same folder and reloaded the .elc file
> (with load-file).  I was expecting that Emacs would create a respective
> .eln file in this situation.  But it didn't.

Please repeat this experiment in a fresh Emacs session, started
when the .el file is already available...

>   Loading d:/tmp/Corwin/strings.elc (compiled; note, source file is
>   newer)...done

...and make sure the .elc file is newer, not older, than the .el file.

> Does this mean that Emacs - by default - is only natively compiling .el
> files which are from Emacs' tree and (M)elpa packages?

No.  Emacs should natively compile any .el file when its .elc file is
loaded, provided that (a) the .el file can be found, and (b) the .el
file is older than the .elc file.

> When (load-file)ing the .el file then Emacs compiled the cl.el library.
> 
>   *Asyn-native-compoile-log* Compiling
>   d:/tmp/Corwin/2022-02-04/share/emacs/28.0.91/lisp/obsolete/cl.el...
> 
>   *Messages* Loading d:/tmp/Corwin/strings.el (source)...
>   d:/tmp/Corwin/strings.el: Warning: ‘psetq’ is an obsolete alias (as of
>   27.1); use ‘cl-psetq’ instead.

As expected.  When you load a file with an explicit .el extension,
Emacs will not natively compile that file -- this is a feature.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]