[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: default coding system when saving
From: |
Alex Schroeder |
Subject: |
Re: default coding system when saving |
Date: |
Sat, 22 Mar 2003 02:20:45 +0100 |
User-agent: |
Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 |
Ah! I was confused. The error message showed the offending
characters like this: ' '
I naturally assumed that the space character between the two was the
offending character. When sending the bug report, however, Gnus
complained about the two apostroph characters!
This put me on the right track, and I found exactly two instances of
the following (I actually replaced the offending byte with the '
char):
character: ' (0222, 146, 0x92)
charset: eight-bit-control (8-bit control code (0x80..0x9F))
code point: 146
syntax: which means: whitespace
category:
buffer code: 0x92
file code: not encodable by coding system iso-latin-1-unix
Unicode: 0092
font: -jmk-Neep Alt-Medium-R-Normal--20-180-75-75-C-100-ISO8859-1
I must have pasted them from somewhere else.
One question remains, however:
While asking me what coding system to use, I am told "The first
problematic character is at point in the displayed buffer, and C-u C-x
= will give information about it." -- but at the same time the
minibuffer is active asking me for a coding system. When I press C-g
to quit, wanting to examing these characters, I find that point is
exactly where I left it.
What is the graceful way of getting out of this situation, and
examine the offending characters?
Alex.
Alex Schroeder <address@hidden> writes:
> I am using a CVS Emacs a few days old.
> I use Latin-1 in my LANG.
> I edit a Latin-1 file.
> I save it.
>
> Sometimes, Emacs complains:
>
> These default coding systems were tried to encode text
> in the buffer `w3mtmp513-0':
> iso-8859-1-unix
> However, each of them encountered these problematic characters:
> iso-8859-1-unix: ' '
> The first problematic character is at point in the displayed buffer,
> and C-u C-x = will give information about it.
>
> Select one of the following safe coding systems, or edit the buffer:
> iso-8859-15 iso-8859-14 utf-8 mule-utf-16-be mule-utf-16-le
> Or specify any other coding system
> on your risk of losing the problematic characters.
>
> This makes no sense, the space character cannot be at fault.
> When I choose iso-8859-15 and save the buffer, the modeline indicates
> this with a 0. When I use find-alternate-file to find the file
> again, the file is opened as Latin-1 again (this makes sense, it is
> my preferred coding system).
>
> How can I debug such a problem in the future?