Peter Dyballa <[EMAIL PROTECTED]> writes: >>> My test files starts with: ;;; -*- coding: iso-8859-6; -*- >> >>> The mode-line starts with -6: >> >>> GNU Emacs 22.0.50 was started with -Q >> >>> When I try to save it I get in mini-buffer: >> >>> Selected encoding mule-utf-8-unix disagrees with iso-8859-6-unix >>> specified by file contents. Really save (else edit coding cookies >>> and try again)? (yes or no) >> >>> Then it's saved in UTF-8 and the mode-line changes to -u:. In another >>> editor (Smultron) I can load the file in ISO 8859-6 encoding and see >>> that it's original encoding was changed to something like UTF-8 (two >>> octets when there was only one before). >> >> iso-8859-6 is an Arabic charset. Didn't the buffer contain >> a character that can't be encoded by iso-8859-6? >> > > The file has some Latin content in the header, and actually there is > only one column of *real* Arabic (our "Latin" digits are indeed > "Arabic"). Smultron is bad in showing wrong characters, GNU Emacs > 23.0.0 does not seem to have ISO 8859-6 support. Re-opening the file > I can see that in one spot a \233 gremlin is sitting, removing it and > trying to save, I get again the question in mini-buffer! (I see > exactly three Arabic glyphs, about 30 were destroyed by Unicode, and > about 30 others are only showed in octal \xyz.) In the mode-lie -6: > is active!
Is this bug still outstanding? _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
