Re: Getting line endings straight.

2010-10-01 Thread Richard Gaskin

David Bovill wrote:


Most of the time we don;t need to worry about line endings - Rev handles
them for us transparently.

...

Some gotcha's:

   - A carriage return is numtochar(13) - however LiveCode internally thinks
   that CR = LF = numtochar(10)
   - On OSX LiveCode does not write out text using the systems native line
   endings - it uses the older Mac Classic line endings (presumably for easier
   compatability)!

The last one I did not know.


Me neither.  Excellent find.  I so rarely use the engine's automatic 
line-changing options that I hadn't come across that before, and in the 
rare case when I do I never noticed because it seems Apple's TextEdit 
renders old-style (ASCII 13) returns just as it does ASCII 10.


Whether this should be changed is an interesting question.  On the one 
hand, it would be nice to remain current, but on the other hand there 
may be many scripts out there that rely on ASCII 13 when on Mac.


How many Mac programs don't render ASCII 13 line endings correctly?

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Getting line endings straight.

2010-10-01 Thread David Bovill
Most of the time we don;t need to worry about line endings - Rev handles
them for us transparently. However, sometimes when workign with external
sources you can get bitten. I thought I'd post this to make sure I've got
things straight, and hopefully clarify things for others. My understanding
is as follows:

   1. LiveCode uses the unix flavoured line ending character internally.
   That is LF or numtochar(10) in LiveCode
   2. LiveCode translates text for you in the background when you use "file
   url's", and open driver, open file, or open processcommands in text mode.
   For example when you use the normal "file" url syntax - ie "put someText
   into url 'file:some.txt'"
   3. On OSX and Linux this is the same as LiveCode's internal line ending
   char = LF or numtochar(10)
   4. On Windows LiveCode would translate the line endings to CRLF =
   numtochar(13) & numtochar(10)
   5. On older Mac Classic systems the line ending character is CR =
   numtochar(13)

Some gotcha's:

   - A carriage return is numtochar(13) - however LiveCode internally thinks
   that CR = LF = numtochar(10)
   - On OSX LiveCode does not write out text using the systems native line
   endings - it uses the older Mac Classic line endings (presumably for easier
   compatability)!

The last one I did not know. Personally I think it is bad behavior, though
most OSX applications handle either form of text file absolutely fine - some
command line tools expect the native unix style line endings (LF). If you
want to use these tools - don't use "file" - for writing out text - use
"binfile".

You can test this on your OSX system using the following in the message box:

put "Hello" & CR & "World" into someText
> put the tempname & ".txt" into someFile
> put someText into url ("file:" & someFile)
> put url ("binfile:" & someFile) contains numtochar(10)
>

Have I got something wrong here - or should we really be asking RunRev to
make it easy for us to read and write text files in native LF mode? Perhaps
there should be an IDE property which we could set base on "the platform",
or perhaps they can tweek their background translation code to keep backward
compatibility, while giving us native line endings on OSX?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution