[OS X TeX] A working version of emacs (fwd)
Peter Dyballa
Peter_Dyballa at Web.DE
Sat May 14 11:18:42 EDT 2005
Allô Bruno!
I needed some time to sort things out and to be finally knowing enough
to answer. I think I've got some news together ...
Am 11.05.2005 um 15:23 schrieb Bruno Voisin:
>
> Not sure whether the following helps, but just in case: in the list of
> unofficial patches <http://sourceforge.jp/projects/macemacsjp/files/>
> inside Seiji Zenitani's Carbon Emacs
> <http://home.att.ne.jp/alpha/z123/emacs-mac-e.html>, there's one
> called mac-utf. And there's mention of utf-8 in the annoucement
> <http://lists.sourceforge.jp/mailman/archives/macemacsjp-english/2005-
> May/000068.html>, for example.
This annoucement is very specific for the Japanese Carbon Emacs. The
mac-utf.el only works in a Japanese language environment (could be in
Chinese or Korean too), and it uses very old software from the more
xemacs related mule-ucs package. This one is obsolete now since it's
functionality is said to be integrated into Carbon Emacs versions
21.3.50 and 22. If I put, as advised, these lines into my .emacs
(require 'un-define)
(require 'mac-utf)
(set-language-environment 'German)
a variable is missing that is defined in one the Japanese specific
files in
/Applications/EmacsJCVS.app/Contents/Resources/site-lisp/site-start.d/,
which should be put aside outside Japan as the ReadMe text recommends.
The patches too are very specific for CJK script systems. Some of the
things mentioned there, are, at least, mis-leading.
file-name-coding-system isn't *exactly* UTF-8, but decomposed UTF-8 in
Mac OS X, because otherwise sorting would be a bit difficult
(decomposed means that ô is saved as o^, in that sequence, NJ becomes NJ
and ǟ is at once a¨¯ or such, which helps a bit when sorting because
now it's not looking up complicated rules but comparison of simple
bytes). The Panther edition still can't work correctly with this. The
Unicode Emacs version 23 now handles it! The file names are sorted
correctly, only the way the glyphs are actually re-composed (instead of
looking them up from the fontset) needs some adaption -- from the
beholder. Ugly isn't precise enough.
The reason that Latin scripts outside the limited Mac-Roman range are
treated so badly is somewhere in the QuickDraw heritage that only knows
Mac-Encodings. All Carbon Emacsen still use the old Apple Type Services
(ATS), while with some Mac OS 9 version ATSUI, the Apple Type Services
for Unicode Imaging, were already introduced. (This too is some synonym
to AAT, Apple's Advanced Typography that makes XeTeX work so fine.) At
least one programmer, Steven Tamm, is turning the font interface to use
ATSUI. Could be I'll break my neck when I'll jump on Christmas to high
into the air -- the ceiling is quite low here at home.
--
Greetings
Pete
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
--------------------- Info ---------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
& FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Post: <mailto:MacOSX-TeX at email.esm.psu.edu>
More information about the MacOSX-TeX
mailing list