[gdal-dev] OT: subversion configuration

[Christopher Barker]

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

Chris.Barker at noaa.gov