[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: x-symbol package dangerous in multibyte environment



 > I am afraid you missed my point. The site-wide installation of
 > x-symbol forces innocent users :-) to change the way how they process
 > their perfectly legal TeX files.  They have either edit them to
 > provide x-symbol specific local variables or to use specific locale
 > even if they regularly use a different one.

In v4.4.3, Emacs and X-Symbol try to do the same thing: dealing with a
non-standard locale (coding system) -- I didn't know that so many people
use that so often.  But of course, only one of them should do it (as
I've said v4.4.4 will be changed accordingly).

With a unibyte XEmacs, having X-Symbol doing the coding system handling
is the only way how people can edit LaTeX docs with latin1 and and other
docs with latin2 8bit characters in the same XEmacs session.  See the
manual why it's good that X-Symbol knows about these things.  You'll see
that everthing is fine with your file if you delete the -*- coding:
iso-latin-2 -*- stuff (yes, you'll see latin2 chars in the buffer).

 > The new buffer is interpreted and displayed as coded in Latin-1 and
 > GNU Emacs asks for choosing a coding system. This is definitely better
 > but still not acceptable.

This is also the case for C-x C-s with Emacs-21.4 (or a corrected
src/fileio.c from Savannah).  In both cases Emacs-21.4 won't ask for a
coding system anymore.  See below why Emacs switches to latin1 (yes,
this bug caused by X-Symbol and will be fixed in v4.4.4).

 > Open `alfabet1.tex', do some minor editing, e.g. add a space on the
 > end of line (or simulate this by C-u M-~) and save the file. You will
 > get rubbish without any warning. To be precise, the file content will
 > be interpreted as Latin-1 and stored in some ISO-2022 coding system
 > using a lot of escape sequences.

The rubbish can be explained as follows: X-Symbol knows that it should
store the latin2 chars as 8bit chars in the file, but at the moment
(4.4.3) does not consider the local -*- coding: ... -*- variable,
i.e. thinks that Emacs expects latin1 chars (to be precise: latin chars
accoding to x-symbol-default-coding, mentioned in the manual).
Therefore X-Symbol performs the recoding to latin1 chars with the same
code positions as corresponding latin2 chars in the buffer.  When saving
the buffer with a latin2 coding system, the latin1 chars will be stored
with the iso-2022 escape sequences for the latin1 chars.

OK, I posted the following at SourceForge.net

Coding Systems / Emacs users:

Emacs users should note:

 * Please wait for v4.4.4 if you use the
   -*-coding:-*- tag for specific files where you
   use X-Symbol.

 * If your default coding system is not
   iso-latin-1, check the value of the variable
   `x-symbol-default-coding' (X-Symbol issues a
   warning, but it is somewhat hidden with Emacs
   before v21.4).  Things will improve with
   X-Symbol-4.4.4.

- Christoph



Reply to: