This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.
Hi Robby, - as I've personally been using OSX for the past few years, I have to admit I forget what peculiarities may have existed under OS9 previously, but as Mac's have historically been the underdog, their text editors have had to become sensitive to various other platform end-of-line encoding, and adopt to it locally. (regardless of UNIX, DOS, or Mac initial encoding). - do agree that all files should be opened in binary mode, but do suspect that it would be nice to adhere to local conventions, and be sensitive to foreign ones; although if one had to pick the most the neutral one, would guess it to be UNIX, as you've chosen. - with respect to utf8, although I wouldn't expect any problems with respect to the use of Scheme's defined character-set; would guess that most programs will continue to interpret non-ASCII encoded character bytes based on their native character-set by default, which aren't presently likely Unicode based (but only relevant to those who expect something otherwise). Thanks, -paul- > From: Robby Findler <robby@xxxxxxxxxxxxxxx> > Date: Sun, 15 Feb 2004 19:03:57 -0600 > To: Paul Schlie <schlie@xxxxxxxxxxx> > Cc: srfi-52@xxxxxxxxxxxxxxxxx > Subject: Re: Encodings. > Resent-From: srfi-52@xxxxxxxxxxxxxxxxx > Resent-Date: Mon, 16 Feb 2004 02:03:59 +0100 (NFT) > > At Fri, 13 Feb 2004 12:15:54 -0500, Paul Schlie wrote: >> (although I suspect that it may be found necessary to >> base read-char, read-string, etc. on a flexibly defined "local" encoding >> definition, rather than assuming all text/data is encoded any particular >> way, on any particular platform.) > > Our experience with the crlf issues on windows vs mac vs unix suggests > the opposite. The desire to be able to distribute a single set of > sources that runs on all those platforms means that we currently read > all files in binary (by default). Whether this translates to unicode > issues isn't entirely clear, but we're starting with a single default > encoding, rather than looking for local encodings. > > Robby >