Ari Jolma wrote:
Why do you need LF on Windows? Why not just use Windows line endings
on windows? With a decent editor is should be completely transparent
anyway.
I use emacs for editing and while there may be a way to configure it to
not to show the ^M, I don't know it.
Emacs can do everything, so I suspect there is a way to get it to deal
with Windows line endings properly. In fact, aside from the spurious ^M,
which you could ignore, I suspect that it is putting in just plain old
LF when you add new line endings, thus resulting in a mixed line ending
file, which is to be avoided. I'd poke around in the Emacs docs and
lists, this should be doable.
This is from:
http://www.gnu.org/software/emacs/windows/big.html
5.6 How can I control CR/LF translation?
There are a number of methods by which you can control automatic CR/LF
translation in Emacs, a situation that reflects the fact that the
default support was not very robust in the past. For a discussion of
this issue, take a look at this collection of email messages on the topic.
5.6.1 Automatic CR/LF translation
For existing files, Emacs scans the file to determine the line ending
convention as part of the same scan it does to determine the file
encoding. Embedded Ctrl-M (ASCII 13) characters and inconsistent line
ends can confuse the automatic scanning, and Emacs will present the file
in Unix (LF) mode with the Ctrl-M characters displayed as `^M'. It does
this to be safe, as no data loss will occur if the file is really binary
and the Ctrl-M characters are significant.
5.6.2 CR/LF translation by file extension
The variable file-name-buffer-file-type-alist holds a list of filename
patterns and their associated type; binary or text. Files marked as
binary will not have line-end detection performed on them, and instead
will always be displayed as is. With auto-detection in recent versions
of Emacs, this is seldom useful for existing files, but can still be
used to influence the choice of line ends for newly created files.
5.6.3 CR/LF translation by file system
The variable untranslated-filesystem-list defines whole directory trees
that should not have CR/LF autodetection performed on them. The list can
be manipulated with the functions add-untranslated-filesystem and
remove-untranslated-filesystem. With auto-detection in recent versions
of Emacs, this is seldom useful for existing files, but can still be
used to influence the choice of line ends for newly created files.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
