Re: [Proposed Patch] button2 on ISO8:T in modeline toggles eol ty pe
"Wedler, Christoph" <christoph.wedler(a)sap.com> writes:
>> 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 #<coding_system
>> 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
iso-2022-8-unix>
> 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. It does work
with MULE XEmacs.
I have the impression that not too many people know what 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. If it is not a new
file, you can't have EOL type nil in that buffer. At least
set-buffer-file-coding-system inherits the current EOL type
if you don't specify it.
> You may say, 'OK, let's change default always'.
But I don't
> think it is a good change because it surprises user
As I said, this has nothing to do with my patch and nothing to do with
the question whether toggle-buffer-coding-system should be able to
change for the current buffer from eol type nil to some other eol type.
I thought we are talking about your proposal of future
enhancement. I'm not specifically talking about your
patch. If you want it to be reviewed, send it to
xemacs-patches. If it is sent to xemacs-beta, I might
or might not comment on it depending on the nature of the
patch.
_*Please USE THE EXISTING toggle-buffer-coding-system and compare
its
behaviour with my mouse-toggle-buffer-coding-system on NEW BUFFERS (C-x
C-f with non-existing files) BEFORE you talk why toggling from eol type
nil to some other (whether unix, dos or mac) is bad.*_
I think no one has commented on your patch so far. Please
calm down and take necessary step for the patch to be
reviewed.
--
Yoshiki Hayashi