Sketches are saved with non-native line endings.

[GoogleCodeExporter]

Create a new sketch on a Windows system, and look at the resulting .pde file:

[heavyweight:~/Public/Arduino/sketch_sep12a] msmith% cat sketch_sep12a.pde 
#include <test.h>
#include <othertest.h>
[heavyweight:~/Public/Arduino/sketch_sep12a] msmith% hexdump -C 
sketch_sep12a.pde
00000000  23 69 6e 63 6c 75 64 65  20 3c 74 65 73 74 2e 68  |#include <test.h|
00000010  3e 0a 23 69 6e 63 6c 75  64 65 20 3c 6f 74 68 65  |>.#include <othe|
00000020  72 74 65 73 74 2e 68 3e  0a 0d 0a                 |rtest.h>...|
0000002b

Note that individual lines are separated with LF, whereas on a Windows system, 
this should be CR LF.

Note also that the file ends in CR LF, suggesting that the code that saves the 
file has considered the entire contents of the file to be a single line.

This seems to be borne out in that Base::save calls PApplet::saveStrings, where 
the latter expects an array of strings, each of which is written as a line to 
the file, but the former calls it with:

  static public void saveFile(String str, File file) throws IOException {
    File temp = File.createTempFile(file.getName(), null, file.getParentFile());
    PApplet.saveStrings(temp, new String[] { str });

which constructs an array of just one string.

The upshot of this is that Arduino creates text files with inconsistent line 
endings; most lines are terminated with LF, but there is a single CR LF 
appended to the end of the file.  This in turn means that tools such as 
Subversion which expect (in some configurations require) native line endings in 
files will refuse to process any file saved by Arduino.

Experiments show that in addition, if a file is created using another Windows 
editor that produces native line endings, the Arduino editor will replace these 
with LF when the file is saved, causing most version control systems to 
consider the entire file modified.

The correct fix would seem to simply involve generating the correct array of 
Strings when passing the sketch either to Base::saveFile, or when 
Base::saveFile calls PApplet::saveStrings.

Original issue reported on code.google.com by DrZip...@gmail.com on 12 Sep 2010 at 8:14