6.1 Lines

AppleScript is a line-based language. There is no visible command terminator, such as a semicolon; a command ends with and is separated from the next command by a line break. For example:

set x to 1
copy x + 1 to y
display dialog y

In a script text file (or other text to be treated as AppleScript code) it doesn't matter whether the line break character is the Macintosh line break (\r), the Unix line break (\n), or the Windows line break (\r\n). Presuming the code is valid, AppleScript will be able to compile it regardless; all line breaks are expressed as Macintosh line breaks on decompilation.

It is legal for a line to be completely blank. Extra whitespace (spaces, tab characters) is legal and will be ignored.

6.1.1 Line Break Characters in Literal Strings

It is legal to type a line break in a literal string (that is, between matched pairs of double-quotes). This represents a line break character within the string. For example:

set pep to "Manny
Moe
Jack"
display dialog pep

Exactly what line break character is represented in this way depends upon the editing environment. In the old Script Editor:

set pep to "Manny
Moe"
pep contains (ASCII character 13) -- true
pep contains (ASCII character 10) -- false

In the new Script Editor:

set pep to "Manny
Moe"
pep contains (ASCII character 13) -- false
pep contains (ASCII character 10) -- true

A returned string value containing a line break character will be displayed (in most contexts) with a visible line break at that point. For example:

set pep to "Manny" & return & "Moe"

The result is displayed like this:

"Manny
Moe"

The same is true of a decompiled string literal containing an "escaped" return character. (Escaped characters in string literals are discussed under Section 13.4.) For example, if you type this:

set pep to "Manny\rMoe"

then when you compile you'll see this:

set pep to "Manny
Moe"

This is generally agreed to be annoying behavior on AppleScript's part. The line break character represented by the keyword return is a Macintosh line break character (\r), which can confuse the display in a Unix context. This is purely a cosmetic issue. For example (in the Terminal):

$ osascript -e 'set pep to "Manny" & return & "Moe"'
Moeny
$ osascript -e 'set pep to "Manny" & (ASCII character 10) & "Moe"'
Manny
Moe

What happened in the first reply is that "Moe" overprinted "Manny".

6.1.2 Continuation Character

Long lines can be broken into multiple lines by typing the continuation character. This character appears as the "logical not" sign; it is MacRoman codepoint 194, Unicode (and WinLatin1 and ISOLatin1) codepoint 172. This character is usually typed on Macintosh as Option-l (that's option-ell); but as a convenience, in a script editing application, typing Option-Return enters both the logical-not character and a return character, and is the usual way of continuing a line.

For example:

set a to ¬
    1

It is a compile-time error for anything to follow the continuation character on the same line other than whitespace.

It is a compile-time error for the line following the continuation character to be blank, unless what precedes the continuation character is a complete command, as in this very silly example:

set a to 1 ¬
        
set b to 2

A continuation character inside a literal string is interpreted as a literal logical-not character. To break a long literal string into multiple code lines for legibility without introducing unwanted return characters into the string, you must concatenate multiple literal strings:

set s to "one very long line " & ¬
        "deserves another"

Under some circumstances, AppleScript will move or remove your continuation characters at compile time. There's nothing you can do about this; it's an effect of the decompilation process. See Section 4.4.2.

In this book, long lines are manually broken for legibility. Continuation characters are inserted to indicate such breaks, without regard for whether AppleScript would move or remove these continuation characters in a compiled version of the script.