If the issue of carriage returns versus linefeeds never causes you any issues, you can probably stop reading now. Otherwise, we hope you will be pleased with the changes to linebreak behaviour we have made in Script Debugger 8.
First, a bit of history. Before OS X, Macs used carriage returns as line-breaks, Windows (and DOS) used a carriage return followed by a linefeed, while Unix, then largely confined to expensive workstations and minicomputers, used linefeeds. When Apple adopted OS X, which was based on Unix, there was a clash.
The answer was to be flexible, and much of the OS accepted any of the three options. The AppleScript compiler, which had been built around carriage returns, was also modified to accept them.
In the early stages, script editors still used Carbon based text editors, which were built around text using carriage returns as line-breaks. Updating to newer Cocoa text editors was mostly straight forward, in that they too happily accepted input with any of the line-break options. So although the AppleScript compiler still produced output with carriage returns as line-breaks – and does to this day – it presented no display problem in the new editors.
There was one area that could cause pain: line-breaks within literal text. Again, passing such text to many apps made no difference because they too were flexible, but for others, using a linefeed instead of a carriage return (or vice-versa) could be disastrous. And spotting the difference in an editing window was impossible.
In the Carbon days, hitting the return key added a carriage return. But in Cocoa text editors, it normally enters a linefeed. So suddenly hitting the same key within literal text gave a different result.
Script Debugger responded in a couple of ways. One was an option to display invisible characters, so you can see whether a line-break is a carriage return or linefeed, and the other was a preference to control what was entered by the return key – so you could set it to enter a carriage return, and it behaved like nothing had changed.
But there was another issue. Some people wanted to store their code elsewhere, in version-control systems, and most of them will not recognize carriage returns as line-breaks. The answer was the ability to specify the line ending when saving a script as text. Unfortunately the implementation Script Editor used, and then Script Debugger matched, was a bit of a sledge-hammer: if you chose to use linefeeds, even carriage returns in literal text were replaced.
(There was a subtle third issue: you could click in some code, hit return, and nothing appeared to happen, because the linefeed you just entered was straight after a carriage return supplied by the compiler, so the editor treated the two characters as a single line-break pair.)
Time has moved on, and the carriage return’s role as a line-break is almost gone. Most scripters have developed workable solutions and learned to live with things, but it’s not something we were happy with. We took a fresh look and came up with a different approach for Script Debugger 8.
In Script Debugger 8, linefeeds rule. Although the AppleScript compiler still produces code with carriage returns as line-breaks, Script Debugger 8 replaces them with linefeeds before passing the source to the document. (Of course no changes are made within literal text.) And when you hit the return key, a linefeed is entered.
That does not mean you cannot have a carriage return in literal text. To enter one, you type \r. And when you compile, you will see the carriage return symbol that was normally only visible with show invisibles turned on. So you can always enter a carriage return, and you will always be able to see where one was entered, avoiding any question of is it or isn’t it.
(The safest thing to do in literal text is to use the defined return and linefeed variables and concatenate, although that’s not always convenient.)
This has also allowed us to simplify saving as text. There are now just two options: macOS (LF), which is effectively what you see in the document on screen, and Legacy (CR), which is same as the old Mac (CR) format, with all linefeeds changed to carriage returns. This macOS option a more sensible setting for text that be stored in a source-control system.
When opening text documents saved by earlier versions, the characters used in the file will be honoured. This means you may see lots of CR symbols at first, but those outside literal text will disappear when the code is compiled, replaced by (invisible) linefeeds.