Re: mac/dos/unix newline conversion without specify from

[Stefan Monnier <monnier@iro.umontreal.ca>]

> <<That's because html-mode sets require-final-newline to t. >>
> Thanks for finding the cause.

That's probably not the cause of your original problem.  It's the cause
of the problem you saw when you tried the replace-string thingy to
replace "all" CRs into LFs.  If you used the C-x RET f mac RET method
I suggested earlier to convert unix-style files to mac-style files, this
problem shouldn't appear.

> Anyhow, for what's worth, i think this is still something emacs (in
> particular Mac versions) should fixup. Basically, the scenario is that
> a user opens mac classic html files, work on it, save it, then next
> time he opens the files shows ^M. (this actually happens to me a lot

That's a clear bug, indeed.  But I can guarantee that it normally works,
so please give us more details so we can track down the problem.
The only know case where a Mac file is misidentified is if it contains
LF chars, which shouldn't happen in normal circumstances.

> since i work on a server with non-professional coders and they use
> BBEdit that is still set to CR as newline) In contrast, i open the
> same file (with CR as eol but a LF at the end) in Xcode, TextWrangler,
> TextEdit, all opens correctly and indicate as Mac files.

The final LF is clearly an error in the file.  You need to track down
its origin.

> * perhaps require-final-newline should insert the right EOL char based
> on the encoding.

It does.


        Stefan