Re: Skipping unexec via a big .elc file

[Ken Raeburn]

On Mar 4, 2017, at 09:23, Eli Zaretskii <address@hidden> wrote:

>>> Also, it looks like the logic in startup.el that should bypass certain
>>> stuff under -Q isn't working, because I see my abbrevs being loaded
>>> even though I invoked "emacs -Q".  Thoughts?
>> 
>> Strange… this is also working for me.  At least, settings from my .emacs 
>> aren’t being applied, when I use “emacs -Q”.
> 
> This problem is still there.  It has nothing to do with loading
> ~/.emacs, though: startup.el always loads your ~/.emacs.d/abbrev_defs,
> if that file exists.  I'm not sure why it loads that file, but I
> verified that the master version does that as well.

Odd, seems like -Q should skip that, with the rest of the user’s 
initializations.

> 
> So the issue here is not that the file is loaded, but how it is
> processed.  I only noticed this because my abbrev_defs file uses a
> function that is only defined in my .emacs.  So "emacs -Q" on the
> raeburn-startup branch barfs because that function is not known.
> Strangely, "emacs -Q" on the master branch doesn't signal an error,
> and I don't even see Fsignal called if I set a breakpoint there.  I
> don't (yet) understand why the different behavior.
> 
> If you insert into your abbrev_defs file something that references a
> function which is not defined, do you see the same problem as I do?

I added a line:

  (missing-function)

in between some define-abbrev-table invocations, and “emacs -Q” on master (2-3 
weeks old) and raeburn-startup both complain about it for me.

> Btw, one thing that I saw while debugging is that purify-flag is set
> to t while running the startup code.  This is because init_alloc_once
> is called during startup (previously, it was only called by temacs).
> I don't know if this is related to the issue (setting purify-flag to
> nil in Frecursive_edit didn't help), but I thought I'd bring it up,
> because maybe we need to set it to nil earlier.

I’ve been thinking that the branch should probably set CANNOT_DUMP 
unconditionally.  The behavior around pure storage and such under CANNOT_DUMP 
is probably closer to what we want for the branch.  But there’s at least one 
bug in building with CANNOT_DUMP for macOS I’ve got to clear up first.  As you 
say, it may not be at all related to the problem you’re running into, though.

Ken