commit: dump make-coding-system
ben at xemacs.org
Thu Feb 25 02:29:37 EST 2010
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)
> ,@(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' ...".
More information about the XEmacs-Patches