Re: Same non-ASCII characters not 'equal'

[James Cloos <cloos@jhcloos.com>]

>>>>> "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>