[OS X TeX] A working version of emacs (fwd)

Peter Dyballa Peter_Dyballa at Web.DE
Sat May 14 17:18:42 CEST 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  
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.



"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 macostex-archives mailing list