Re: [tlug] GNU EMacs & Japanese files

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "ijw" == ijw  <ijw@example.com> writes:

    ijw> Now, any chance I can persuade it it would like to use a
    ijw> readable Japanese font as opposed to the strange italicised
    ijw> (or brushed, but in any case horrendously pixellated) thing
    ijw> it's rendering at the moment?

Dunno; Windows font handling is one of the things I just plain don't
grok.  Unfortunately, the menus just plain don't work for non-Latin
fonts yet, and I don't think Andy bothered to implement the font
dialog when he added dialog support.  :-(

If you know the Windows name (which probably is the obvious analog to
what appears in a Windows font dialog), then

(set-face-font 'default "MS Mincho:12:::Japanese")

probably should get you 90% of the way.  (Don't take that font name
seriously, I'm going from memory of a comment in a C source file
... IIRC ....)

    ijw> Also, reading the change documentation, I'm curious to know
    ijw> how the GC mechanism has been rewritten for XEmacs.

Actually, as yet it's the same old GC, but it has been reimplemented
in preparation for working on better alternatives.

A short digression is necessary.  For many years the unexec process
has been a major annoyance, but with the entrance of stuff like the
"Hannibal Lector" linker and the "We Could Tell You Where We'll Load
You, But Then We'd Have To kill(1) You" security extensions, it's
become untenable.  Anyway, we borrowed Guido's time machine, and
implemented a portable dumper just in time to not have to revise our
Linux ELF unexec for the "Hannibal Lector" linker.

It turns out that the memory description records used to figure out
where portably dumped data came from and put it back where XEmacs can
find it at runtime are basically the same information that modern
garbage collectors need.  So Mike Sperber and his students at
U. Tuebingen extended the memory descriptors slightly and rewrote the
existing garbage collector to use them (that's the --enable-kkcc
option).  One of his students (Marcus Crestani) has written a new
allocator (the --enable-mc-alloc option), but I don't know much about
it.  This also required unifying the representation of lrecords and
elcrecords.  I guess he intends to implement a new GC on top of that
soon (anyway, Mike won't sign off on his MS until he does ;-).

    ijw> I've recall seeing some suggestion for a Lisp garbage
    ijw> collector that involved scanning the stack directly for
    ijw> consblock references, which may have been vrey efficient but
    ijw> looked totally appalling...

It's not really an issue of efficiency; that will come from a
generational collector or something like that.  Rather, the current GC
relies on being told which memory cells contain references to Lisp data,
which in the C code means using the GCPRO macros to protect that data.
Unfortunately, it's like any memory management by hand---highly error
prone.  Nor are these minor errors; they're double frees, dangling
pointers, and other hobgoblins.  Talk about appalling!  "Conservative"
collectors in theory avoid such errors; in practice they also tend to
overprotect garbage, producing memory leaks (or more likely long lags
in collection).

Anyway, probably the most commonly used C library for GC, the Boehm
collector, uses this strategy.  A couple of people have actually
hooked up the Boehm collector to XEmacs, but performance was pretty
horrible IIRC.  (They didn't try very hard, though.)

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.