Yoshiki Hayashi wrote:
> "Wedler, Christoph" <christoph.wedler(a)sap.com> writes:
>> > (setq file-coding-system-alist
>> > (append file-coding-system-alist '(("." . undecided-dos)))
>>
>> > as a workaround?
>>
>> It doesn't work:
>>
>> 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).
Thus I would use your default only in a dos-only environment.
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.
But this has nothing to do with my proposed patch. This patch only
allows to change the eol type nil for a buffer (i.e., the file has been
read and (1) doesn't apply anymore). toggle-buffer-coding-system w/o my
patch just does nothing in this case.
>> BTW, I haven't seen one reason by anyone, why toggling from eol type nil
>> to some other (whether unix, dos or mac) is bad.
> OK, if you insist...
> First, it simply doesn't work.
> You have LF and you want it to conver to CR. You need to do M-x
> toggle-buffer-coding-system twice to get CR from LF. Then the
> default becomes CRLF even if the last one choosed by user is LF.
First, toggle-buffer-coding-system does doesn't change any default, it
changes the buffer-file-coding-system. Thus I don't know what you're
trying to say here.
> 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.
The default question a seperate issue: I want to able to customize what
eol type nil means, see (2) above. But of course, Unix users won't
change the default.
> If the functionality to change default EOL type is desired, it should
> be done by different function. The above are reason why I think
> overloading toggle-buffer-coding-system is not a good idea.
How should a patch in toggle-buffer-coding-system be able to change the
functionality of the eol type nil. Please read above what
toggle-buffer-coding-system (without and with my patch) does.
Thus, still haven't seen one reason by anyone, why toggling from eol
type nil to some other (whether unix, dos or mac) is bad.
_*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.*_
- Christoph
