[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Same non-ASCII characters not 'equal'
From: |
James Cloos |
Subject: |
Re: Same non-ASCII characters not 'equal' |
Date: |
Thu, 17 Aug 2006 12:49:01 -0400 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.0 (gnu/linux) |
>>>>> "Sebastian" == Sebastian Tennant <sebyte@smolny.plus.com>
>>>>> writes:
>> You are probably ending up with the 8859-1 (Latin 1) version of
>> U+00E7 LATIN SMALL LETTER C WITH CEDILLA in the elisp; using the
>> turkish-postfix input method most likely uses 8859-9 (Latin 5).
Sebastian> I don't think this is the problem as I'm working with a
Sebastian> unicode terminal, and the encodings used for read and write
Sebastian> are mule-utf-8
It is still possible that turkish-postfix generates a latin5 ç rather
than a mule-utf-8 ç. But, no. I get the same buffer code when using
turkish-postfix as when using X’s “<Multi_key> <,> <c>”. (That w/o
anything interesting in ~/.emacs but with LANG=en_US-UTF8 run on a sid
box with emacs-snapshot-nox installed via apt.)
Sebastian> Everything is mule-utf-8.
Then my guess was a red herring. I don’t know what the problem is.
>> Since I’ve moved almost exclusively to the unicode-2 branch, I
>> don’t remember the specifics of the unify-8859 modes, but they are
>> documented in info.
Sebastian> I'm not sure what you mean by unicode-2 branch
Sebastian> (emacs-version) "GNU Emacs 21.4.1 (i486-pc-linux-gnu)
Sebastian> of 2006-05-15 on trouble, modified by Debian"
The unicode-2 branch is a branch of the Emacs CVS repository. You can
grab it from cvs by using:
cvs -d :pserver:cvs.savannah.gnu.org:/cvsroot/emacs co -r emacs-unicode-2 emacs
instead of using:
cvs -d :pserver:cvs.savannah.gnu.org:/cvsroot/emacs co emacs
which grabs the HEAD branch.
The HEAD branch is to be released as Emacs-22. The emacs-unicode-2
branch is likely to be the basis of the Emacs-23 release.
On debian, you can get a compile of snapshots of the HEAD branch by
installing emacs-snapshot, emacs-snapshot-nox or emacs-snapshot-gtk
rather than using emacs, emacs-nox, emacs21 or emacs21-nox. (On sid
what you are running would be emacs21 or emacs21-nox, as applicable.
What is emacs21 on sid *may* be just emacs on sarge. I’m not sure
about etch. Emacs-snapshot *might* handle this better than emacs21
does. Or it might not. I’m confident that the unicode-2 branch,
however, will get it right. But on debian you’ll have to compile it
yourself. (On ubuntu, emacs-snapshot is certainly available for edgy
and — I *think* — for dapper; I’ve not tried anything older than that.)
Sebastian> I've managed to establish that the problem is caused by
Sebastian> either the read or write to disk, or both. If the
Sebastian> dictionary is defined in the function, matches are found
Sebastian> without a problem. It's only when the dictionary is
Sebastian> populated from disk when matches of non-ASCII characters
Sebastian> fail.
Try running (describe-char) with the point on the offending characters
in the buffer containing the data as read from disk. If they don’t
match what you get from (describe-char) on the freshly keyboard-input
characters then my guess was on the mark after all. Or at least in
the same ballpark ☺ — or the same football pitch, if you prefer.
If that is the case, I presume you need to set the coding-system for
reading in the dictionary data as mule-utf-8.
-JimC
--
James Cloos <cloos@jhcloos.com>