Re: font or face problem in emacs

[Peter Dyballa <Peter_Dyballa@Web.DE>]

Am 30.06.2006 um 01:34 schrieb H.S.:

> Peter Dyballa wrote:
>
>> Make the *compilation* buffer be encoded in UTF-8 or make your  
>> LANG  or LC_CTYPE environment variables 8 bit -- could be there is  
>> some  option in your g++ to stay in 8 bit when printing some message.
>
> Yes, that is one method. But with all this talk of systems being  
> utf-8 compatible and such these days, I was expecting that  
> applications are getting better at this. If Emacs is not UTF-8  
> complaint, I would like to know for sure so that I can accomodate  
> other applications I use. On the other hand, if Emacs is expected  
> to recognize UTF-8, then there ought to be a way to make it do so  
> by default. All I want to know is which way is it?
>

GNU Emacs 21.4 is probably missing a lot (I don't use it, I 21.3.50  
from CVS around), version 22.0.50 is far away from an UTF-8  
application, at least with my customisation. GNU Emacs 23.0.0  
performs better, but has problems, too.

In 21.3.50 and 22.0.50 *shell* and dired buffers seem to have  
problems with UTF-8 file names, although in *shell* I can 'cat'  
kermit's utf_8.txt and some 10K glyphs are displayed. *compilation*  
or *Completions* work fine. It depends on your demands ...

Sometime in GNU Emacs 21.x code was introduced to read LANG and/or  
LC_CTYPE and prepare some default encoding of buffers based an these  
environment variables. Since then it's not necessary to set terminal  
or keyboard or clipboard or ... coding systems. There is much code  
that outputs only 7bit or 8bit messages. You can see from my *shell*  
example that most things work, but some don't. In GNU Emacs 23 for  
example the method of Mac OS X's HFS+ file system to store UTF-8 file  
names as decomposed characters leads to file names that look ugly  
because some mechanism builds from a and ¨ an ä. And somehow the  
combining modifier ¨ is not positioned correctly ... When the  
character is prêt-à-porter, "composed," as in kermit's utf_8.txt,  
then it looks fine -- but the fonts to display these characters  
change to so that the glyphs used do not fit in size and other  
parameters.

If there were a monospaced Unicode encoded font without gaps to span  
from SPACE to REPLACEMENT CHARACTER ([�] at FFFD) it wouldn't be so  
ugly. (There are two more PLANES with each 64K characters defined in  
Unicode 4.x.)

--
Greetings

   Pete

There are two major products that come out of Berkeley: LSD and UNIX.  
We don't believe this to be a coincidence.
                                          - Jeremy S. Anderson