help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Xah Lee
Subject: Re: mac/dos/unix newline conversion without specify from
Date: Fri, 7 Dec 2007 10:03:20 -0800 (PST)
User-agent: G2/1.0

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
  address@hidden
\xAD\xF4 http://xahlee.org/



On Dec 5, 9:05 am, David Kastrup <address@hidden> wrote:
> Xah Lee <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]