Re: Skipping unexec via a big .elc file

[Ken Raeburn]

On Jan 14, 2017, at 05:41, Eli Zaretskii <address@hidden> wrote:
> It does fail for me while byte compiling 2 files:

I still haven’t hit these.

> The category '>' is defined in characters.el.  Surprisingly,
> characters.elc in this branch is identical to the file on master, so
> byte compilation (see below) is off the hook here.  What else could
> explain that this category is deemed unknown?

I recently noticed the standard syntax and category tables don’t appear to be 
among the information dumped out, so anything set by characters.el isn’t 
preserved.  I also didn’t see an existing way to restore them trivially.  (A 
huge list of “modify-syntax-entry” calls and such seems impractical.)  Also, 
the buffer-local nature of some variables was being lost; that presented itself 
as a failure to get syntax-based highlighting in C source files.

Having patched around these, I’m still failing on the same file, but later; it 
prompts me for the coding system to use to write an output file, because it’s 
not valid UTF-8.  Apparently the leading comments copied from SKK-JISYO.L are 
being corrupted.  The first non-ASCII bytes in the buffer (in the 
“ACKNOWLEDGEMENTS” part of the comment) are 0xe3, 0x81, 0x93, 0xe3, 0x81, 0xae, 
0xe8 in a normal build and 0xf5, 0x80, 0x84, 0xac, 0xf5, 0x80, 0x85, 0x87 in my 
build.  I discovered this maybe half an hour ago, so that’s as far as I’ve 
gotten.

I’ve just pushed my changes, plus your change to avoid the dump-emacs call, to 
the branch.  Saving and restoring the standard syntax table seems cheap, 
because it was already referenced by other objects that were dumped out, but 
the standard category table almost doubles the size of my dumped.elc, and 
presumably increases the time to read it accordingly.  Perhaps reading 
characters.el(c) at startup would be a better choice.

Ken