cr, lf, and reading in terminals/vim

Ben Rubinstein benr_mc at cogapp.com
Thu Oct 31 11:16:14 EDT 2019


> My suggestion is to just bite the bullet and build LC where 'file' exports
> using LF on Mac

Oh please yes!

It's been 18 years since the Mac standardised on LF. (And AFAIK Metacard only 
started supporting the Mac eight years before that, so 
Metacard/Revolution/LiveCode has already been writing the 'wrong' files for 
twice as long as it was writing the 'right' ones.)

As you say, it's moot on import to LC; so the only instance where this change 
could cause a compatibility issue would be where an LC-based tool is 
generating files for consumption by some other system which is dependent on 
them being CR format. Such a tool is presumably going to be Mac based - a 
Windows or *nix system would be more likely to reject that format than depend 
on it, if it accepts the format it's probably sophisticated enough to accept 
LF as well. So we're talking about a Mac based system which is still running 
but which in 18 years hasn't been updated to at least also accept the native 
format of the OS that it runs on. And this will only be an issue if someone 
updates their app producing these files to the latest version of LC (in which 
case they will surely anyway be having to take special precautions and write 
the file as binary to avoid confusing an ancient system with UTF8??). I don't 
know if such a case exists; I certainly doubt if there are very many such.

Brian - what would be required before you could submit your work as a PR again?

Ben


On 31/10/2019 03:26, Brian Milby via use-livecode wrote:
> My suggestion is to just bite the bullet and build LC where 'file' exports
> using LF on Mac.  The change required is literally a couple of characters
> in one file (maybe two files to include the server default, but you can
> already change it there on demand).  Leave the constants as they are (LF).
> It could be announced as something for 9.6 to give the community time to
> test.  The only way it would be a problem is if you were exporting a text
> file on a Mac that was going to be consumed by a program that depended on
> CR line endings.
> 
> Since LC consumes all 3 formats equally well, it would be no issue on the
> read side.
> 
> Internally the concern is the build tools/environment.  I've built LC with
> it changed (actually submitted it as part of a PR, but had to reverse it)
> before 9 was GM.  It passed the automated tests when I did it.
> 
> On Wed, Oct 30, 2019 at 10:28 PM Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> Brian Milby wrote:
>>
>>   > The reason for the difficulty is that internally LC uses LF as the
>>   > line ending.  The cr, lf, and return constants all actually map to LF.
>>   > When you write a text file, LC will convert line endings to the native
>>   > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
>>   > I take issue with this because as of OS X the native line ending for
>>   > the OS is actually now LF...
>>
>> Agreed.
>>
>> The hard question is: What shall we do about it?
>>
>> On the one hand, we have millions of lines of code in our community that
>> use CR, and a certain percentage of those are dependent on CR having a
>> specific value (even if that value is inconsistent with the true ASCII
>> value).
>>
>> On the other hand, we have a constant that suggests it's one thing when
>> it's really something else, and at this point that design decision
>> benefits no one and confuses many.
>>
>> Favor backward compatibility, or language learnability/usability?
>>
>> --
>>    Richard Gaskin
>>    Fourth World Systems
>>    Software Design and Development for the Desktop, Mobile, and the Web
>>    ____________________________________________________________________
>>    Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list