On Thu, Sep 22, 2011 at 4:47 PM, Glenn Maynard wrote:
>> "native" Newlines must be transformed to the default line-ending
>> representation of the underlying host filesystem. For example, if the
>> underlying filesystem is FAT32, newlines would be transformed into \r\n
>> pairs as the text was app
On Thu, Sep 22, 2011 at 7:47 PM, Glenn Maynard wrote:
> > "native" Newlines must be transformed to the default line-ending
> representation of the underlying host filesystem. For example, if the
> underlying filesystem is FAT32, newlines would be transformed into \r\n
> pairs as the text was appe
On Fri, Sep 23, 2011 at 4:36 AM, Simon Pieters wrote:
> Can we get away with always using \n?
>
Not if you want to be interoperable with native applications. You can't
even open a text file in Notepad with Unix line endings.
(Another reason "underlying host filesystem" doesn't make sense: this
On Fri, 23 Sep 2011 01:47:15 +0200, Glenn Maynard wrote:
"native" Newlines must be transformed to the default line-ending
representation of the underlying host filesystem. For example, if the
underlying filesystem is FAT32, newlines would be transformed into \r\n
pairs as the text was appended
> "native" Newlines must be transformed to the default line-ending
representation of the underlying host filesystem. For example, if the
underlying filesystem is FAT32, newlines would be transformed into \r\n
pairs as the text was appended to the state of the BlobBuilder.
This is a bit odd: most p
