Re: [Emacs-diffs] scratch/raeburn-startup a4231c3 4/5: Don't dump artifacts of the dump process.

Re: [Emacs-diffs] scratch/raeburn-startup a4231c3 4/5: Don't dump artifacts of the dump process.

[Stefan Monnier]

> +                                     ;; Any let-bound variables during
> +                                     ;; dump process will be useless.
> +                                     faces coding-systems coding-system-aliases
> +                                     charsets charset-aliases unified-charsets
> +                                     abbrev-tables abbrev-counter
> +                                     abbrev-make-cmds abbrev-assign-cmds
> +                                     cmds))))

Converting to lexical-binding would solve these more cleanly, I think.


        Stefan

Re: [Emacs-diffs] scratch/raeburn-startup a4231c3 4/5: Don't dump artifacts of the dump process.

[Ken Raeburn]

On Apr 10, 2017, at 14:13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> +                                     ;; Any let-bound variables during
>> +                                     ;; dump process will be useless.
>> +                                     faces coding-systems coding-system-aliases
>> +                                     charsets charset-aliases unified-charsets
>> +                                     abbrev-tables abbrev-counter
>> +                                     abbrev-make-cmds abbrev-assign-cmds
>> +                                     cmds))))
> 
> Converting to lexical-binding would solve these more cleanly, I think.
> 
> 
>        Stefan

We do have “lexical-binding:t” at the top of the file, but still the let-bound variables’ local bindings are showing up in the output.

Ken

Re: [Emacs-diffs] scratch/raeburn-startup a4231c3 4/5: Don't dump artifacts of the dump process.

[Stefan Monnier]

> We do have “lexical-binding:t” at the top of the file, but still the
> let-bound variables’ local bindings are showing up in the output.

Oh, right, because the lexical-binding:t cookie doesn't take effect
since we haven't yet loaded the Elisp code which pays attention to it.


        Stefan

Re: [Emacs-diffs] scratch/raeburn-startup a4231c3 4/5: Don't dump artifacts of the dump process.

[Ken Raeburn]

On Apr 12, 2017, at 07:46, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> We do have “lexical-binding:t” at the top of the file, but still the
>> let-bound variables’ local bindings are showing up in the output.
> 
> Oh, right, because the lexical-binding:t cookie doesn't take effect
> since we haven't yet loaded the Elisp code which pays attention to it.

This is probably going to make my brain hurt, but… how does that work?  At the point where we do the “let” we’ve already loaded the Lisp code we’re going to dump.  Or is it something that needs to be in effect when we start loading the file?  Maybe something we can explicitly enable after loading the necessary Lisp bits?  If we can’t use lexical binding in loadup.el, maybe we should change the file header to not appear as though we’re enabling it.

Also, does this issue affect Lisp code loaded as .el source from loadup while bootstrapping?

Ken

Re: [Emacs-diffs] scratch/raeburn-startup a4231c3 4/5: Don't dump artifacts of the dump process.

[Stefan Monnier]

> This is probably going to make my brain hurt, but… how does that work?

I can't remember exactly.  Actually, I think it is supposed to work
correctly, thanks to some C code in lread.c (see
lisp_file_lexically_bound_p), but apparently it doesn't work here.
Not sure why.

> going to dump.  Or is it something that needs to be in effect when we start
> loading the file?

Yes.

> Maybe something we can explicitly enable after loading
> the necessary Lisp bits?

We could, but it's delicate.

> If we can’t use lexical binding in loadup.el,
> maybe we should change the file header to not appear as though we’re
> enabling it.

Indeed, tho hopefully we can make it work.


        Stefan