commit: dump make-coding-system

[Ben Wing]

On Tue, Feb 23, 2010 at 3:11 PM, Aidan Kehoe <kehoea at parhasard.net> wrote:
>
>  Ar an tríú lá is fiche de mí Feabhra, scríobh Ben Wing:
>
>  > lisp/ChangeLog addition:
>  >
>  > 2010-02-22  Ben Wing  <ben at xemacs.org>
>  >
>  >      * mule/make-coding-system.el:
>  >      * mule/make-coding-system.el (fixed-width-generate-helper):
>  >      * mule/make-coding-system.el (fixed-width-private-use-start): Removed.
>  >      * mule/make-coding-system.el (fixed-width-create-decode-encode-tables):
>  >      * coding.el:
>  >      * coding.el (decode-char): New.
>  >      * coding.el (featurep):
>  >      * coding.el (encode-char): New.
>  >      * dumped-lisp.el (preloaded-file-list):
>  >      Dump make-coding-system.  Aidan's hack to avoid dumping this file
>  >      never really worked right -- with some configurations (not clear
>  >      exactly which ones)
>
> This happens when a core file, byte-compiled with non-Mule, is loaded at
> dump time from a Mule build, because the compiler macro in
> mule/make-coding-system,.el--in particular, this part of it:
>
>    [...]
>    (if (byte-compile-constp type)
>        ;; This is not a fixed-width call; compile it to a form that 21.4
>        ;; can also understand.
>        `(funcall (or (and (fboundp 'make-coding-system-internal)
>                           'make-coding-system-internal)
>                      'make-coding-system)
>          ,@(cdr form))
>    [...]
>
> was not available on non-Mule. This is not something that ever bites normal
> users, just people developing, and the simple way around it is to add a
> compiler macro on non-Mule.
>
>  >      `make-coding-system.el' gets dumped anyway due to
>  >      calls to `make-coding-system' in unicode.el, with the result that
>  >      the documentation of functions in make-coding-system.el gets lost.
>  >
>  >      Also needed to remove defvar fixed-width-private-use-start and
>  >      incorporate it inline, due to bootstrapping issues -- the call to
>  >      decode-char introduced a cross-dependency between unicode.el and
>  >      make-coding-system.el.
>
> You’re also added duplicate definitions for encode-char and decode-char;
> they’re now both in unicode.el and coding.el . And dropping the docstring
> for fixed-width-private-use-start was not a net positive! Though I admit we
> saw an issue with the decode-char call in byte-compiling the packages; it
> would have been better to have declared it like so in the first place:
>
> (defvar fixed-width-private-use-start ?\uE000 ...)
>
> I’d like to back out your change, add the compiler macro as above, and
> change the declaration of fixed-width-private-use-start. Do you object?

Go ahead.  I never quite understood why I didn't run into the problem
always, but I see now that the compiler macro is making the calls to
make-coding-system disappear under Mule.

You might want to rewrite the doc string of
`make-coding-system-internal' so that when people see it in non-Mule
it makes a bit more sense -- currently they will check the doc of
`make-coding-system' and see "See `make-coding-system' ...".

ben