Yoshiki Hayashi [yoshiki(a)xemacs.org]:
"Wedler, Christoph" <christoph.wedler(a)sap.com>
> >> 1. Use the above appended list
> >> 2. Open a new file foo.txt with two line of "ab".
> >> 3. You see the modeline is still "ISO8" (and
> >> `buffer-file-coding-system' is iso-2208-8), but this would be
> >> acceptable, although not nice (since I also see ISO8 for Unix
> >> endings and ISO8:T for dos)
> >> 4. Save the buffer, the length is 6 bytes (i.e., Unix endings)
> >> 5. Kill the buffer, re-read it.
> >> 6. Modeline ISO8:T, and `buffer-file-coding-system' is
> >> iso-2022-8-dos> -- huh?
> >> 7. delete your entry from file-coding-system-alist
> >> 8. Kill the buffer, re-read it.
> >> 9. Modeline ISO8, and `buffer-file-coding-system' is #<coding_system
> > Did you try this?
> > (setq-default default-buffer-file-coding-system 'iso-8859-1-dos)
> Yes, it's better that it really write files with dos endings (i.e, 4
> above is OK now), but when reading files with unix eol type, the buffer
> has a coding system with dos eol type (i.e., 6 is still strange).
Then you found a bug in file-coding XEmacs.
Well, it doesn't contradict the docstring of
Default value of `buffer-file-coding-system' for buffers that do not
override it. This is the same as (default-value
'buffer-file-coding-system). This value is used both for buffers
without associated files and for buffers whose files do not have any
apparent coding system.
If you set `default-buffer-file-coding-system' to `iso-2022-8-dos' and
visit a Unix file with ASCII-only characters, this file doesn't probably
have a "apparent coding system", that's why the corresponding is
The eol type of the file is apparent, but not the whole coding system.
If the two properties "base" and "eol type" should be considered
independently, this should be mentioned in the docstring, and the
current behaviour of XEmacs should be considered wrong as you've said.
It does work with MULE XEmacs.
Maybe XEmacs-21.5.X, but not on the following:
./configure '--with-png=no' '--site-includes=/sapmnt/hw1020/a/include'
XEmacs 21.4.5 "Civil Service" configured for `hppa1.1-hp-hpux11.00'.
> [...] eol type nil means:
> (1) when reading: XEmacs tries to guess the correct eol type
> (2) when writing: XEmacs uses its internal eol type which is unix' one.
> I definitely want to have (1), that is, no, I don't want to set a
> variable which uses a specific eol type to read a file.
> But there is no auto-guess functionality when saving the buffer. That
> is I want to say that eol type nil can also mean dos or mac when writing
> the file.
XEmacs should not attempt to auto-guess EOL when saving buffer and
should never be. It uses whatever the value of
buffer-file-coding-system. EOL type nil is not auto-guess in this
case but means LF for new file.
Err, yes... The wording in my previous message wasn't good: I just
wanted to say (in the section starting with "But there is no..." and in
earlier messages) that it would be useful to be able to customize that
eol type nil when saving can mean CRLF (or CR) instead of LF.
If it is not a new file, you can't have EOL type nil in that
Exactly. That's why I always talked about new files when arguing why
toggling from eol type nil is useful...
I thought we are talking about your proposal of future enhancement.
Except for the above mentioned variable ("able to customize"), I didn't
mention any others.
I'm not specifically talking about your patch.
Well, this is exactly my problem. Toggling from eol type nil in a
buffer is specific to that patch, people vetoed that feature and when I
asked "why?", people start talking about something else (if there was an
answer at all).
That's why I got annoyed. Sorry that it sounded like I was specific
annoyed with your answer.
I think no one has commented on your patch so far.
Err, some people vetoed the feature "toggling from eol type nil in a
buffer" and some agreed with the veto. Before sending a patch, it
would be useful to get a reason for that or that they take the veto back
(otherwise I put work in a patch which will be vetoed).
 To which one should be customizable (I already agreed on that)