GNU bug report logs - #66022
30.0.50; kmacro overwriting global keybindings

Previous Next

Full log

Message #125 received at 66022 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66022 <at> debbugs.gnu.org
Subject: Re: bug#66022: 30.0.50; kmacro overwriting global keybindings
Date: Mon, 18 Sep 2023 19:54:40 +0200

On 23-09-18 19:00 , Stefan Monnier wrote:
>> Sorry, missed copying a line from the terminal
>> 
>> / >  ls -l 
>> /Applications/Emacs.app/Contents/Resources/lisp/loaddefs.el* 
>> -rw-r--r--  1 gerd  admin   377687 Sep 17 16:36 
>> /Applications/Emacs.app/Contents/Resources/lisp/loaddefs.el.gz 
>> -rw-r--r--  1 gerd  admin  1467107 Sep 17 16:38 
>> /Applications/Emacs.app/Contents/Resources/lisp/loaddefs.elc 
>> gerd <at> Pro 2023-09-18 18:32 ~/ >
> 
> I believe the `lread.c` code which calls `Fload` should be looking at
> the `loaddefs.elc` file here, so removing the `.el.gz` should make no
> difference.
> 
> Now why does it feel the need to reload this file?  The way the code
>  works is that it receives a (FILE . POS) pair where FILE should 
> presumably point to the `loaddefs.elc`.
> 
> When it opens that `.elc` file, POS should point to the beginning of 
> the desired docstring with nearby info indicating the length of that 
> docstring.
> 
> If the file was changed in the mean time, POS may end up pointing 
> elsewhere.  `lread.c` performs a sanity check to make sure POS
> points to something that does indeed look like a docstring and
> apparently in your case that sanity check fails.
> 
> My crystal ball suggests maybe you're witnessing a bug in the build 
> process where we end up *re*compiling `loaddefs.elc` a second time 
> (maybe because we regenerate/refresh `loaddefs.el` by error) after 
> Emacs was dumped, maybe during the "install" step that builds the 
> `Emacs.app`.
> 
> Normally, the way things are supposed to work is:
> 
> - build temacs. - dump bootstrap-emacs using some old 
> `loaddefs.el(c)` of `ldefs-boot.el`. - compile the preloaded files 
> and build the true `loaddefs.el`. - dump the final `emacs` 
> executable. - keep compiling the rest.
> 
> But if "keep compiling the rest" ends up touching a dependency of 
> `loaddefs.el` subsequent steps like `install` could decide to make 
> poor decisions :-(
> 
> IOW rebuild, keeping a log and check what was done in which order.

Ok, I'll try that during the next days.  (Have to finally replace the
battery of the old Macbook, and the display for the mini is not working.)

Do you think the following plan make ssense?

- I assume that a build from git clean -xdf shows all the steps that
must happen with 100% certainty.

- I'd then make bootstrap + look for a difference.

- Then same procedure for simple make in the toplevel dir,
   - after there is only a C file changed
   - after only a Lisp file is changed

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.