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@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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
