(I’ll also ask this at the manufacturers of Script Debugger; but perhaps some of you have run into this as well)
A company I sometimes work for uses Script Debugger. I might want to buy it, but I saw a weird bug:
--textedit doc contains words, one per line, line 1 contains the word one, line 2 contains the word two etc
--they have to go into a list
tell document 1 of application "TextEdit"
activate
set theText to (text of document 1 of application "TextEdit")
set AppleScript's text item delimiters to "r" --return character
set thelist to text items of theText as list
end tell
Just run it in normal Applescript mode: it works fine.
The list contains: one, two, three, etc. as separate list items
Then run it in Applescript debugger mode and it fails:
the list contains one item: one%0atwo%0athree
The return delimiter is not recognised! This is a nasty bug, since I do a lot of text parsing. Do I have to look around for another debugger or is there a fix?
The problem is that Script Debugger converts all new-line characters in source code to CR following a compile. Since TextEdit uses Unix (LF) line endings, you have a problem.
Just use a more explicit means of specifying line endings:
tell document 1 of application "TextEdit"
activate
set theText to (text of document 1 of application "TextEdit")
set AppleScript's text item delimiters to ASCII character 10 --LF character
set thelist to text items of theText as list
end tell
You can use LFs (in all editors, I think) as follow:
tell document 1 of application "TextEdit"
set theText to (text of document 1 of application "TextEdit")
set AppleScript's text item delimiters to "n" --will compile as ASCII 10
set thelist to text items of theText as list
end tell
Anyway, there is a workaround which should extract what you wish from a text, whatever are its line-endings (CR, LF, CRLF):
tell document 1 of application "TextEdit"
set theText to paragraphs of (get text of document 1 of application "TextEdit")
end tell
