Yoshiki Hayashi wrote:
"Wedler, Christoph" <christoph.wedler(a)sap.com>
> If you set `default-buffer-file-coding-system' to
> and visit a Unix file with ASCII-only characters, this file doesn't
> probably have a "apparent coding system", that's why the [buffer's
> `buffer-file-coding-system'] is `#<coding_system iso-2022-8-dos>'.
You mean there's no LF in that file? If a file does not have
XEmacs has no way to autodetect it. So in that case, you are seeing
the correct behavior.
There are LFs in the file. [Not in Yoshiki's citation:]
> The eol type of the file is apparent, but not the whole coding
I meant the same file I was talking about earlier in this thread: two
lines, each containing "ab" (phew, I'm lucky, ASCII includes the control
characters ;-)). As I said, the above mentioned behaviour might have
changed in XEmacs-21.5.X.
BTW, setting `default-buffer-file-coding-system' to `iso-2022-8-dos' is
even worse when reading this file if it has CR (Mac) endings: then I get
a buffer with one line: ab^Mab^M (no line ending)
I still think chaning default-buffer-file will solve most of the
This might be true in an environment where files have an "apparent coding
system" (probably Japanese), but not with ASCII-only files: files with
LF endings would be saved with CRLF the next time and files with CR
endings would be read as files with one line (see above)
but I have no objection to applying your patch.
As I said, it's OK for me that the patch will be applied for 21.5 only.
The "[I'll send the patch] if I know the status of my other patches" was
just an info: it's easier for me that way (and the patch is for 21.5.X
anyway = no urgency here), it wasn't meant to give those other patches