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

[Xah Lee]

David Kastrup wrote:
<<That's because html-mode sets require-final-newline to t. >>

Thanks for finding the cause.

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
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.

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

* perhaps emacs file opening routine should be more smart. (i.e. not
using the last EOL, or check more lines, to determine the EOL char)

(note: this post contains the french double quote char "<<>>" (unicode
00AB 00BB). Google groups may have botched it to <<>> or omitted it)

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/



On Dec 5, 9:05 am, David Kastrup <d...@gnu.org> wrote:
> Xah Lee <x...@xahlee.org> writes:
> > Xah Lee wrote:
> > <<Open a unix file, do replace-string from LF to CR. Save the file.
> > Then start emacs with -q, open the file. It doesn't interprete the
> > file as a mac os classic file but instead display newline char as ^M.>>
>
> > David Kastrup wrote:
> > <<
> > It does switch to Mac endings here in this case.  Just tried it.
>
> > mm... interesting. Here's a sample file for what's worth:
> >http://xahlee.org/emacs/x-unixmacdos-eol/x1mac
>
> That's because html-mode sets require-final-newline to t.  If you reset
> it to nil and then save, you get the file saved without a final
> (non-Macish-looking) LF character, and it gets recognized correctly when
> loading it again.
>
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum