Piet van Oostrum wrote:
[EMAIL PROTECTED] (Tomas Zerolo) (TZ) wrote:
TZ> Ah. You have to distinguish between Emacs's internal representation
TZ> (that's possibly the 2276 you mention), which doesn't change (al least
TZ> unless you try hard ;) and what is in the file (how Emacs writes or
TZ> interprets what it reads). You can change those things changing the
TZ> coding system (look for something like `multilingual environment').
By default Emacs uses different internal representations for the "same"
character in different coding systems. So a iso-8859-1 "ä" is a different
thing than a utf-8 "ä". This difference will disappear when Emacs switches
to Unicode internally. For the time being the OP could use Unicode
unification, if his Emacs version is young enough. I have used this for
some years now without any problems. Maybe it solves the original problem.
(require 'ucs-tables)
(unify-8859-on-encoding-mode 1)
(unify-8859-on-decoding-mode 1)
The values I have I have in CVS emacs.exe -Q is
(featurep 'ucs-tables) = t
unify-8859-on-encoding-mode = t
unify-8859-on-decoding-mode = nil
Though I do not understand what it means right now ;-)
Evaling (unify-8859-on-decoding-mode 1) does not change the behaviour of
C-q 3 4 4 RET. It still enters a character that (following-char) reports as
2276 (04344, 0x8e4)
I did not notice before that there only seem to be on bit that differs
(see the second figure) - if that in some way matters.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
