On 22 Μαρ 2008, at 12:34 ΜΜ, Peter Dyballa wrote:
>
> 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.
>
Right. I think I had read somewhere that in Mac OS X environment
variables aren't set in the shell's startup file, but rather in the ~/
MacOSX/environment.plist file. Coming from Linux, I put the LC_*
variables in the shell's startup file, and forgotten to remove them
after. Should I put them in ~/MacOSX/environment.plist?
>>
>>
>>> 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
I added this line to my ~/.emacs.
> 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.
>
I understand. Unfortunately it seems that this is not the case, as the
path doesn't seem to contain any Greek characters that might be
decomposed; there are only capital Greek letters without any
diacritics (only some plain underscores in between). (The name of the
file itself contain only latin characters.)
> 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
Doing as you suggested, with C-u C-x = on the directory, I get the
following:
---------------------------------------------------------------------------------------------------------------------------------
character: SPC (32, #o40, #x20)
preferred charset: ascii (ASCII (ISO646 IRV))
code point: 0x20
syntax: which means: whitespace
category: a:ASCII graphic characters 32-126 (ISO646 IRV:
1983[4/0]) l:Latin
buffer code: #x20
file code: not encodable by coding system nil
display: by this font (glyph code)
DejaVuSansMono (#x03)
Character code properties are not shown: customize what to show
There are text properties here:
auto-composed t
fontified t
----------------------------------------------------------------------------------------------------------------------------------
> 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).
>
I checked, and no MULE references exist in the .emacs file.
> --
> Greetings
>
> Pete
>
> It's not the valleys in life I dread so much as the dips.
> – Garfield
>
>
>
Thanks very much
-------------------------------------------------------------------------
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-
