unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
@ 2022-11-17  9:28 Juanma Barranquero
  2022-11-17 12:07 ` Eli Zaretskii
  0 siblings, 1 reply; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-17  9:28 UTC (permalink / raw)
  To: 59334

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

emacs -Q
M-x byte-compile-file <RET> ~/.emacs.d/init.el <RET>
C-x C-c
emacs
;;; init.el is now native-compiled
C-h v user-init-file <RET>
;;; => "d:/mypath/Home/.emacs.d/init.el"
C-x C-c
emacs
C-h v user-init-file <RET>
;;; =>
"d:/mypath/Home/.emacs.d/native/29.0.50-a4a10996/init-7890dda9-d677a456.eln"

[-- Attachment #2: Type: text/html, Size: 1012 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-17  9:28 bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln Juanma Barranquero
@ 2022-11-17 12:07 ` Eli Zaretskii
  2022-11-17 13:30   ` Juanma Barranquero
  0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-17 12:07 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 17 Nov 2022 10:28:44 +0100
> 
> emacs -Q
> M-x byte-compile-file <RET> ~/.emacs.d/init.el <RET>
> C-x C-c
> emacs
> ;;; init.el is now native-compiled
> C-h v user-init-file <RET>
> ;;; => "d:/mypath/Home/.emacs.d/init.el"
> C-x C-c
> emacs
> C-h v user-init-file <RET>
> ;;; => "d:/mypath/Home/.emacs.d/native/29.0.50-a4a10996/init-7890dda9-d677a456.eln"

After the last step, what does the below produce:

  M-: (gethash "init-7890dda9-d677a456.eln" comp-eln-to-el-h) RET





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-17 12:07 ` Eli Zaretskii
@ 2022-11-17 13:30   ` Juanma Barranquero
  2022-11-17 14:00     ` Eli Zaretskii
  0 siblings, 1 reply; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-17 13:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334

[-- Attachment #1: Type: text/plain, Size: 102 bytes --]

M-: (gethash "init-7890dda9-d677a456.eln" comp-eln-to-el-h) RET

=> "d:/mypath/Home/.emacs.d/init.el"

[-- Attachment #2: Type: text/html, Size: 283 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-17 13:30   ` Juanma Barranquero
@ 2022-11-17 14:00     ` Eli Zaretskii
  2022-11-17 20:04       ` Andrea Corallo
  0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-17 14:00 UTC (permalink / raw)
  To: Juanma Barranquero, Andrea Corallo; +Cc: 59334

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 17 Nov 2022 14:30:27 +0100
> Cc: 59334@debbugs.gnu.org
> 
> M-: (gethash "init-7890dda9-d677a456.eln" comp-eln-to-el-h) RET
> 
> => "d:/mypath/Home/.emacs.d/init.el"

OK, thanks.  So using this, can you propose a patch for
startup--load-user-init-file, where it figures out the name of
user-init-file?  It happens in this fragment:

            ;; If we loaded a compiled file, set `user-init-file' to
            ;; the source version if that exists.
            (when (equal (file-name-extension user-init-file)
                         "elc")
              (let* ((source (file-name-sans-extension user-init-file))
                     (alt (concat source ".el")))
                (setq source (cond ((file-exists-p alt) alt)
                                   ((file-exists-p source) source)
                                   (t nil)))
                (when source
                  (when (file-newer-than-file-p source user-init-file)
                    (message "Warning: %s is newer than %s"
                             source user-init-file)
                    (sit-for 1))
                  (setq user-init-file source))))

Note that the gethash trick I suggested needs a _basename_ of the .eln
file, without any leading directories.

(It is best if you propose a patch because it should be easy for you
to test it.)

Andrea, do you agree with this solution?





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-17 14:00     ` Eli Zaretskii
@ 2022-11-17 20:04       ` Andrea Corallo
  2022-11-17 20:09         ` Eli Zaretskii
  0 siblings, 1 reply; 22+ messages in thread
From: Andrea Corallo @ 2022-11-17 20:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juanma Barranquero, 59334

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Thu, 17 Nov 2022 14:30:27 +0100
>> Cc: 59334@debbugs.gnu.org
>> 
>> M-: (gethash "init-7890dda9-d677a456.eln" comp-eln-to-el-h) RET
>> 
>> => "d:/mypath/Home/.emacs.d/init.el"
>
> OK, thanks.  So using this, can you propose a patch for
> startup--load-user-init-file, where it figures out the name of
> user-init-file?  It happens in this fragment:
>
>             ;; If we loaded a compiled file, set `user-init-file' to
>             ;; the source version if that exists.
>             (when (equal (file-name-extension user-init-file)
>                          "elc")
>               (let* ((source (file-name-sans-extension user-init-file))
>                      (alt (concat source ".el")))
>                 (setq source (cond ((file-exists-p alt) alt)
>                                    ((file-exists-p source) source)
>                                    (t nil)))
>                 (when source
>                   (when (file-newer-than-file-p source user-init-file)
>                     (message "Warning: %s is newer than %s"
>                              source user-init-file)
>                     (sit-for 1))
>                   (setq user-init-file source))))
>
> Note that the gethash trick I suggested needs a _basename_ of the .eln
> file, without any leading directories.
>
> (It is best if you propose a patch because it should be easy for you
> to test it.)
>
> Andrea, do you agree with this solution?

Hi Eli,

yes, I'd have suggested the same.

  Andrea





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-17 20:04       ` Andrea Corallo
@ 2022-11-17 20:09         ` Eli Zaretskii
  2022-11-18  2:25           ` Juanma Barranquero
  0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-17 20:09 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: lekktu, 59334

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>, 59334@debbugs.gnu.org
> Date: Thu, 17 Nov 2022 20:04:42 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Andrea, do you agree with this solution?
> 
> Hi Eli,
> 
> yes, I'd have suggested the same.

Great, thanks.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-17 20:09         ` Eli Zaretskii
@ 2022-11-18  2:25           ` Juanma Barranquero
  2022-11-18  2:56             ` Juanma Barranquero
                               ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18  2:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, Andrea Corallo

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

This fix works. It assumes (as the original code does) that the source will
either be an .el file, or extensionless (though when an .eln was loaded,
the source will always be .el), so the following code will check for
staleness of the .elc as usual.

In other words, with this patch, it will still warn if the source file is
newer than the .elc (as it does now Emacs), regardless of whether the init
file was loaded from an .elc or .eln. (The age of the .eln is irrelevant
here, that's for the native compiler to check and act upon.)


diff --git i/lisp/startup.el w/lisp/startup.el
index 70267fc857..62984426e5 100644
--- i/lisp/startup.el
+++ w/lisp/startup.el
@@ -1064,7 +1064,11 @@ startup--load-user-init-file
             ;; If we loaded a compiled file, set `user-init-file' to
             ;; the source version if that exists.
-            (when (equal (file-name-extension user-init-file)
-                         "elc")
-              (let* ((source (file-name-sans-extension user-init-file))
+            (when (member (file-name-extension user-init-file)
+                          '("elc" "eln"))
+              (let* ((source (file-name-sans-extension
+                              (or (gethash
+                                   (file-name-nondirectory user-init-file)
+                                   comp-eln-to-el-h)
+                                  user-init-file)))
                      (alt (concat source ".el")))
                 (setq source (cond ((file-exists-p alt) alt)


Testing this patch allowed me to discover another bug:

If you use ~/.emacs instead of ~.emacs.d/init.el, and happen to compile
.emacs, Emacs loads .emacs.elc (as it has always done), but the native
compiler does *not* know how to compile it (because it does not know how to
locate its source), so it gives a warning:

022-11-18 02:54:01+0100 Warning (comp): Cannot look up eln file as no
source file was found for d:/Home/.emacs.elc

and then it assigns the user-init-file to warnings.el!

ELISP> user-init-file
"d:/Home/.emacs.d/native/29.0.50-a4a10996/warnings-28e75f4d-02da775e.eln"

which, if my patch is installed, gets converted to its source file:

ELISP> user-init-file
"d:/Devel/emacs/repo/trunk/lisp/emacs-lisp/warnings.el"

So this is a double bug for anyone compiling their .emacs: they will always
get a warning, and an erroneous user-init-file.

Do you want me to file this as a separate bug?

[-- Attachment #2: Type: text/html, Size: 3169 bytes --]

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  2:25           ` Juanma Barranquero
@ 2022-11-18  2:56             ` Juanma Barranquero
  2022-11-18  3:03               ` Juanma Barranquero
  2022-11-18  7:19             ` Eli Zaretskii
  2022-11-18  7:27             ` Eli Zaretskii
  2 siblings, 1 reply; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18  2:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, Andrea Corallo

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Fri, Nov 18, 2022 at 3:25 AM Juanma Barranquero <lekktu@gmail.com> wrote:

> In other words, with this patch, it will still warn if the source file is
newer than the .elc
> (as it does now Emacs), regardless of whether the init file was loaded
from an .elc or
> .eln. (The age of the .eln is irrelevant here, that's for the native
compiler to check and
> act upon.)

Sorry, this part is not true. It's comparing the source with
user-init-file. Let me fix that and get back.

[-- Attachment #2: Type: text/html, Size: 1278 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  2:56             ` Juanma Barranquero
@ 2022-11-18  3:03               ` Juanma Barranquero
  2022-11-18  7:50                 ` Eli Zaretskii
  0 siblings, 1 reply; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18  3:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, Andrea Corallo

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

Hmm. Before I start changing it...

If the init file was loaded from .eln, do we want it to warn the user
- when init.el is newer than init.elc, or
- when init.el is newer than [whatever]/init-xxxxxxxx-yyyyyyy.eln (as it's
doing now)?

[-- Attachment #2: Type: text/html, Size: 347 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  2:25           ` Juanma Barranquero
  2022-11-18  2:56             ` Juanma Barranquero
@ 2022-11-18  7:19             ` Eli Zaretskii
  2022-11-18  7:27             ` Eli Zaretskii
  2 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-18  7:19 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334, akrl

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 18 Nov 2022 03:25:34 +0100
> Cc: Andrea Corallo <akrl@sdf.org>, 59334@debbugs.gnu.org
> 
> If you use ~/.emacs instead of ~.emacs.d/init.el, and happen to compile .emacs, Emacs loads .emacs.elc
> (as it has always done), but the native compiler does *not* know how to compile it (because it does not know
> how to locate its source), so it gives a warning:
> 
> 022-11-18 02:54:01+0100 Warning (comp): Cannot look up eln file as no source file was found for
> d:/Home/.emacs.elc
> 
> and then it assigns the user-init-file to warnings.el!
> 
> ELISP> user-init-file
> "d:/Home/.emacs.d/native/29.0.50-a4a10996/warnings-28e75f4d-02da775e.eln"
> 
> which, if my patch is installed, gets converted to its source file:
> 
> ELISP> user-init-file
> "d:/Devel/emacs/repo/trunk/lisp/emacs-lisp/warnings.el"
> 
> So this is a double bug for anyone compiling their .emacs: they will always get a warning, and an erroneous
> user-init-file.
> 
> Do you want me to file this as a separate bug?

Yes, please.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  2:25           ` Juanma Barranquero
  2022-11-18  2:56             ` Juanma Barranquero
  2022-11-18  7:19             ` Eli Zaretskii
@ 2022-11-18  7:27             ` Eli Zaretskii
  2022-11-18  7:45               ` Juanma Barranquero
  2 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-18  7:27 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334, akrl

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 18 Nov 2022 03:25:34 +0100
> Cc: Andrea Corallo <akrl@sdf.org>, 59334@debbugs.gnu.org
> 
> diff --git i/lisp/startup.el w/lisp/startup.el
> index 70267fc857..62984426e5 100644
> --- i/lisp/startup.el
> +++ w/lisp/startup.el
> @@ -1064,7 +1064,11 @@ startup--load-user-init-file
>              ;; If we loaded a compiled file, set `user-init-file' to
>              ;; the source version if that exists.
> -            (when (equal (file-name-extension user-init-file)
> -                         "elc")
> -              (let* ((source (file-name-sans-extension user-init-file))
> +            (when (member (file-name-extension user-init-file)
> +                          '("elc" "eln"))
> +              (let* ((source (file-name-sans-extension
> +                              (or (gethash
> +                                   (file-name-nondirectory user-init-file)
> +                                   comp-eln-to-el-h)
> +                                  user-init-file)))
>                       (alt (concat source ".el")))
>                  (setq source (cond ((file-exists-p alt) alt)

I think the call to gethash should only be done if the file has the
.eln extension, otherwise you might have false positives.

The logic should be something like

  . if the extension is .eln then
    - try to get the corresponding .el file by gethash
    - if that fails, leave user-init-file to be the original .eln
      file name, perhaps with a warning
    - otherwise, set user-init-file to the .el file from gethash
  . else <the original logic which yields .el or .elc>

The file-exists-and-is-newer test is not relevant to the .eln case,
because Emacs will not load a .eln file that is outdated wrt its
source, and will not use a .eln file whose source is not available.
Andrea, please correct me if I'm wrong.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  7:27             ` Eli Zaretskii
@ 2022-11-18  7:45               ` Juanma Barranquero
  2022-11-18  8:46                 ` Eli Zaretskii
  0 siblings, 1 reply; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18  7:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, akrl

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Fri, Nov 18, 2022 at 8:28 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I think the call to gethash should only be done if the file has the
> .eln extension, otherwise you might have false positives.

Do you mean the hash comp-eln-to-el-h could have keys that match something
that doesn't end in .eln? Or that someone could've an init file with
extension .eln and matching one of the keys? Both seem extremely unlikely,
but ok.

> The file-exists-and-is-newer test is not relevant to the .eln case,
> because Emacs will not load a .eln file that is outdated wrt its
> source, and will not use a .eln file whose source is not available.

Ok. Easier, then.

[-- Attachment #2: Type: text/html, Size: 916 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  3:03               ` Juanma Barranquero
@ 2022-11-18  7:50                 ` Eli Zaretskii
  0 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-18  7:50 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334, akrl

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 18 Nov 2022 04:03:32 +0100
> Cc: Andrea Corallo <akrl@sdf.org>, 59334@debbugs.gnu.org
> 
> If the init file was loaded from .eln, do we want it to warn the user
> - when init.el is newer than init.elc, or
> - when init.el is newer than [whatever]/init-xxxxxxxx-yyyyyyy.eln (as it's doing now)?

The second one cannot happen, AFAIU: Emacs will not load an outdated
.eln file.  That's why Emacs insists on having access to the .el
source file when it is about to load a .eln file.

As for the first one, I'm not sure if a warning is necessary.  For
starters, it will be a very rare one, since when we compile to produce
an updated .eln file, we also produce an updated .elc file.  And
emitting a warning in that case might confuse users, making them think
Emacs loaded the .elc file (otherwise why should Emacs bother about
its being outdated?).

So, on balance, I think the answer is NO to both.

Andrea, WDYT?





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  7:45               ` Juanma Barranquero
@ 2022-11-18  8:46                 ` Eli Zaretskii
  2022-11-18  9:05                   ` Juanma Barranquero
  2022-11-18 10:39                   ` Andrea Corallo
  0 siblings, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-18  8:46 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334, akrl

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 18 Nov 2022 08:45:03 +0100
> Cc: akrl@sdf.org, 59334@debbugs.gnu.org
> 
> > I think the call to gethash should only be done if the file has the
> > .eln extension, otherwise you might have false positives.
> 
> Do you mean the hash comp-eln-to-el-h could have keys that match something that doesn't end in .eln? Or
> that someone could've an init file with extension .eln and matching one of the keys? Both seem extremely
> unlikely, but ok.

I thought about a possibility that the session loaded a .eln file, but
then the user or some Lisp explicitly loaded the .el file by hand.
I'm not sure in this case the hash table is updated.  Andrea, am I
right?





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  8:46                 ` Eli Zaretskii
@ 2022-11-18  9:05                   ` Juanma Barranquero
  2022-11-18  9:08                     ` Juanma Barranquero
  2022-11-18 12:33                     ` Eli Zaretskii
  2022-11-18 10:39                   ` Andrea Corallo
  1 sibling, 2 replies; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18  9:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, akrl

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

On Fri, Nov 18, 2022 at 9:46 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I thought about a possibility that the session loaded a .eln file, but
> then the user or some Lisp explicitly loaded the .el file by hand.
> I'm not sure in this case the hash table is updated.

That's a whole another problem, isn't it?

On one hand, it would not affect user-init-file, as it's not the usual
startup procedure. And, on the other hand, my patch sets user-init-file to
the source .el, so after reloading that file it would still have the right
value, wouldn't it?

Anyway, here's the reworked patch.

diff --git i/lisp/startup.el w/lisp/startup.el
index 70267fc857..d7d8743336 100644
--- i/lisp/startup.el
+++ w/lisp/startup.el
@@ -1064,17 +1064,25 @@ startup--load-user-init-file
             ;; If we loaded a compiled file, set `user-init-file' to
             ;; the source version if that exists.
-            (when (equal (file-name-extension user-init-file)
-                         "elc")
-              (let* ((source (file-name-sans-extension user-init-file))
-                     (alt (concat source ".el")))
-                (setq source (cond ((file-exists-p alt) alt)
-                                   ((file-exists-p source) source)
-                                   (t nil)))
-                (when source
-                  (when (file-newer-than-file-p source user-init-file)
-                    (message "Warning: %s is newer than %s"
-                             source user-init-file)
-                    (sit-for 1))
-                  (setq user-init-file source))))
+            (if (equal (file-name-extension user-init-file) "elc")
+                (let* ((source (file-name-sans-extension user-init-file))
+                       (alt (concat source ".el")))
+                  (setq source (cond ((file-exists-p alt) alt)
+                                     ((file-exists-p source) source)
+                                     (t nil)))
+                  (when source
+                    (when (file-newer-than-file-p source user-init-file)
+                      (message "Warning: %s is newer than %s"
+                               source user-init-file)
+                      (sit-for 1))
+                    (setq user-init-file source)))
+              ;; Else, perhaps the user init file was compiled
+              (when (equal (file-name-extension user-init-file) "eln")
+                (if-let (source (gethash (file-name-nondirectory
user-init-file)
+                                         comp-eln-to-el-h))
+                    ;; source exists or the .eln file would not load
+                    (setq user-init-file source)
+                  (message "Warning: unknown source file for init file %S"
+                           user-init-file)
+                  (sit-for 1))))

             (when (and load-defaults


The original code is untouched, other than changing `when' to `if'; the
else part deals with the .eln.

I've checked that gethash returns a value, but not for the file's existence
because in that case comp already complains:

2022-11-18 10:01:15+0100 Warning (comp): Cannot look up eln file as no
source file was found for d:/Home/.emacs.d/init.elc

The warning above is only for the unlikely case that user-init-file points
to an .eln but the gethash lookup returns nil.

[-- Attachment #2: Type: text/html, Size: 5082 bytes --]

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  9:05                   ` Juanma Barranquero
@ 2022-11-18  9:08                     ` Juanma Barranquero
  2022-11-18 12:33                     ` Eli Zaretskii
  1 sibling, 0 replies; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18  9:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, akrl

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

On Fri, Nov 18, 2022 at 10:05 AM Juanma Barranquero <lekktu@gmail.com>
wrote:

> The warning above is only for the unlikely case that user-init-file
points to an .eln
> but the gethash lookup returns nil.

Meaning the warning I've added in my code, not the warning I pasted about
the missing .el, of course.

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  8:46                 ` Eli Zaretskii
  2022-11-18  9:05                   ` Juanma Barranquero
@ 2022-11-18 10:39                   ` Andrea Corallo
  1 sibling, 0 replies; 22+ messages in thread
From: Andrea Corallo @ 2022-11-18 10:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juanma Barranquero, 59334

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Fri, 18 Nov 2022 08:45:03 +0100
>> Cc: akrl@sdf.org, 59334@debbugs.gnu.org
>> 
>> > I think the call to gethash should only be done if the file has the
>> > .eln extension, otherwise you might have false positives.
>> 
>> Do you mean the hash comp-eln-to-el-h could have keys that match something that doesn't end in .eln? Or
>> that someone could've an init file with extension .eln and matching one of the keys? Both seem extremely
>> unlikely, but ok.
>
> I thought about a possibility that the session loaded a .eln file, but
> then the user or some Lisp explicitly loaded the .el file by hand.
> I'm not sure in this case the hash table is updated.

In that case (manual load af an .el file) the hash table is just not
updated (and still all the keys in it should be only .eln files).

  Andrea





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18  9:05                   ` Juanma Barranquero
  2022-11-18  9:08                     ` Juanma Barranquero
@ 2022-11-18 12:33                     ` Eli Zaretskii
  2022-11-18 12:40                       ` Juanma Barranquero
  2022-11-18 20:02                       ` Andrea Corallo
  1 sibling, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-18 12:33 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334, akrl

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 18 Nov 2022 10:05:50 +0100
> Cc: akrl@sdf.org, 59334@debbugs.gnu.org
> 
> > I thought about a possibility that the session loaded a .eln file, but
> > then the user or some Lisp explicitly loaded the .el file by hand.
> > I'm not sure in this case the hash table is updated. 
> 
> That's a whole another problem, isn't it?

Not necessarily.

> On one hand, it would not affect user-init-file, as it's not the
> usual startup procedure.

It could be part of startup if the forced loading of "init.el" is in
the code inside user's init file itself.  Crazy, I know, but not
impossible.

> And, on the other hand,
> my patch sets user-init-file to the source .el, so after reloading that file it would still have the right value,
> wouldn't it?

If that is the same file, yes.  But what if there's an init.el in
another place?

In any case, we don't need to keep arguing about this, since your
pat6ch indeed uses gethash only if the init file has the .eln
extension.

> The original code is untouched, other than changing `when' to `if'; the else part deals with the .eln.

I think we should compare the extensions case-insensitively, but other
than that, this LGTM.

Andrea, any comments?

> I've checked that gethash returns a value, but not for the file's existence because in that case comp already
> complains:
> 
> 2022-11-18 10:01:15+0100 Warning (comp): Cannot look up eln file as no source file was found for
> d:/Home/.emacs.d/init.elc
> 
> The warning above is only for the unlikely case that user-init-file points to an .eln but the gethash lookup
> returns nil.

SGTM, thanks.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18 12:33                     ` Eli Zaretskii
@ 2022-11-18 12:40                       ` Juanma Barranquero
  2022-11-18 12:50                         ` Eli Zaretskii
  2022-11-18 20:02                       ` Andrea Corallo
  1 sibling, 1 reply; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18 12:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, akrl

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Fri, Nov 18, 2022 at 1:33 PM Eli Zaretskii <eliz@gnu.org> wrote:

> It could be part of startup if the forced loading of "init.el" is in
> the code inside user's init file itself.  Crazy, I know, but not
> impossible.

I suppose I'm not devious enough to think of that possibility ;-)

> I think we should compare the extensions case-insensitively, but other
> than that, this LGTM.

Hmm. I can use `string-equal-ignore-case', if you want, but the original
code was already checking for "el" case-sensitively.

If so, do you want it just when checking for .eln, or for .el above also?

[-- Attachment #2: Type: text/html, Size: 986 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18 12:40                       ` Juanma Barranquero
@ 2022-11-18 12:50                         ` Eli Zaretskii
  2022-11-18 13:03                           ` Juanma Barranquero
  0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2022-11-18 12:50 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 59334, akrl

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 18 Nov 2022 13:40:44 +0100
> Cc: akrl@sdf.org, 59334@debbugs.gnu.org
> 
> Hmm. I can use `string-equal-ignore-case', if you want, but the original code was already checking for "el"
> case-sensitively.

Actually, forget about this.  It could mean complications with unibyte
file names at startup, so let's leave this alone.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18 12:50                         ` Eli Zaretskii
@ 2022-11-18 13:03                           ` Juanma Barranquero
  0 siblings, 0 replies; 22+ messages in thread
From: Juanma Barranquero @ 2022-11-18 13:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59334, akrl

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

close 59334 29.0.50
quit

Fixed by commit

c116d9f74c  of  2022-11-18  Avoid `user-init-file' being set to an eln file
(bug#59334)

[-- Attachment #2: Type: text/html, Size: 365 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln
  2022-11-18 12:33                     ` Eli Zaretskii
  2022-11-18 12:40                       ` Juanma Barranquero
@ 2022-11-18 20:02                       ` Andrea Corallo
  1 sibling, 0 replies; 22+ messages in thread
From: Andrea Corallo @ 2022-11-18 20:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juanma Barranquero, 59334

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Fri, 18 Nov 2022 10:05:50 +0100
>> Cc: akrl@sdf.org, 59334@debbugs.gnu.org
>> 
>> > I thought about a possibility that the session loaded a .eln file, but
>> > then the user or some Lisp explicitly loaded the .el file by hand.
>> > I'm not sure in this case the hash table is updated. 
>> 
>> That's a whole another problem, isn't it?
>
> Not necessarily.
>
>> On one hand, it would not affect user-init-file, as it's not the
>> usual startup procedure.
>
> It could be part of startup if the forced loading of "init.el" is in
> the code inside user's init file itself.  Crazy, I know, but not
> impossible.
>
>> And, on the other hand,
>> my patch sets user-init-file to the source .el, so after reloading that file it would still have the right value,
>> wouldn't it?
>
> If that is the same file, yes.  But what if there's an init.el in
> another place?
>
> In any case, we don't need to keep arguing about this, since your
> pat6ch indeed uses gethash only if the init file has the .eln
> extension.
>
>> The original code is untouched, other than changing `when' to `if'; the else part deals with the .eln.
>
> I think we should compare the extensions case-insensitively, but other
> than that, this LGTM.
>
> Andrea, any comments?

Agree and I don't have any further comment.

Thanks

  Andrea





^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-11-18 20:02 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-17  9:28 bug#59334: 29.0.50; loading native-compiled init file sets user-init-file to .eln Juanma Barranquero
2022-11-17 12:07 ` Eli Zaretskii
2022-11-17 13:30   ` Juanma Barranquero
2022-11-17 14:00     ` Eli Zaretskii
2022-11-17 20:04       ` Andrea Corallo
2022-11-17 20:09         ` Eli Zaretskii
2022-11-18  2:25           ` Juanma Barranquero
2022-11-18  2:56             ` Juanma Barranquero
2022-11-18  3:03               ` Juanma Barranquero
2022-11-18  7:50                 ` Eli Zaretskii
2022-11-18  7:19             ` Eli Zaretskii
2022-11-18  7:27             ` Eli Zaretskii
2022-11-18  7:45               ` Juanma Barranquero
2022-11-18  8:46                 ` Eli Zaretskii
2022-11-18  9:05                   ` Juanma Barranquero
2022-11-18  9:08                     ` Juanma Barranquero
2022-11-18 12:33                     ` Eli Zaretskii
2022-11-18 12:40                       ` Juanma Barranquero
2022-11-18 12:50                         ` Eli Zaretskii
2022-11-18 13:03                           ` Juanma Barranquero
2022-11-18 20:02                       ` Andrea Corallo
2022-11-18 10:39                   ` Andrea Corallo

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).