Am 22.03.2008 um 01:57 schrieb Christos Chryssochoidis:
>> I don't seem to be able to reproduce it with German umlauts. Do
>> you set some language-environment? Are in your process-environment
>> LANG or LC_CTYPE or LC_ALL defined?
>>
>
> Thanks very much for the response. Yes, from the Mac OS X terminal
> I get LC_ALL=el_GR.UTF-8.
What's in Terminal does not necessarily exist also in Emacs' process-
environment (a variable) because the way applications are launched in
Mac OS X are different from other UNIX versions in that no shell is
used in this step. So all shell based environment variables are
invisible.
>
>
>> The function set-language-environment should better be avoided
>> with modern Emacsen, at least with Unicode Emacsen like Emacs.app.
>> It's more of an auxiliary function for 8 bit Emacsen. LC_CTYPE
>> helps modern Emacsen to prepare encodings.
>>
>
> I have a (latex) file with non latin characters, and at first,
> whenever I opened it with Emacs.app, the non-latin characters
> appeared garbled. So I went to Options > Mule > Set Language
> Environment > UTF-8. You mention about LC_CTYPE; LC_CTYPE (as
> LC_ALL) is defined in my .profile file (both to el_GR.UTF-8).
> Still, before making the aforementioned setting in Mule menu, the
> non-latin characters appeared garbled.
>
> Trying to reproduce the garbling of the characters in my file,
> reverting the setting Mule > Set Language Environment > Default,
You should not use MULE in modern Emacsen. It's a hack from last
millennium, meant to handle issues of a 7 or 8 bit programme in the
real world of 16 or 32 bits.
If LC_ALL does not exist in process-environment, a statement like
(setenv "LC_ALL" "el_GR.UTF-8")
in ~/.emacs should provide it. Having this variable set does not cure
problems of displaying particular characters. In this case you'd need
to select a font that has many Latin glyphs and also provides Greek.
Polytonic Greek bears another problem: the character is in the file
and path name decomposed to the basic un-accented character followed
by the "accents." A German ä or French à becomes the sequence of a
+ ¨ or a + `. Similarly a Greek ΰ is decomposed to ϋ + ´ – and
since it's possible to decompose GREEK SMALL LETTER UPSILON WITH
DIALYTIKA to υ + ¨ the ΰ might end up as three characters: υ + ¨
+ ´. Although Emacs.app seems to be able to handle this for example
in dired-mode or in *Buffer List* and *Messages* it fails to do so in
file name completion.
What you might check is a directory listing in dired that contains
the directory with the Greek character(s). You can position the text
cursor on the Greek character(s) and type C-u C-x =. A new *Help*
buffer will appear that possibly also shows the character's
decomposition. This might depending on setting or customising the
variable unicodedata-file to point to the file UnicodeData.txt or
UnicodeDataFull.txt. I have, in Tiger/Mac OS X 10.4.11, for example /
System/Library/Perl/5.8.6/unicore/UnicodeData.txt (also in
ActivePerl-5.8.x) or /Library/Frameworks/FTX.framework/Versions/A/
Resources/UnicodeData.txt. The same file is also in XeTeX or Emacs
sources (as emacs/admin/unidata/UnicodeData.txt) or comes with xindy,
CLisp, kermit, UnicodeChecker. Maybe you can find out whether the
crashes happen with characters that can be decomposed to more than
two characters – without MULE. I think you should remove all MULE
references from ~/.emacs (keeping the elder file under a different
name in case I am wrong).
--
Greetings
Pete
It's not the valleys in life I dread so much as the dips.
– Garfield
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Emacs-app-dev- mailing list
Emacs-app-dev-@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emacs-app-dev-
