When I open a .applescript file in SD, there is no syntax coloring. SE would do syntax coloring after a save, but SD requires the script to be run to trigger syntax coloring. Why is that ? I would have thought that syntax coloring would run out of the box even for text files?
Btw, the reason why I want to work with .applescript files is because I want to start to put my files under git management. If there is another convenient solution in SD, I’m a taker.
Syntax coloring is the result of compiling, and it can’t be saved in a .applescript file because that’s just text. If you open one in either SD or SE, it won’t be syntax formatted until you compile it – indeed, a .applescript file can be saved in a state where it won’t compile.
So it means there is no way to have VC and syntax coloring in SD ?
No. Compiled scripts are a binary format. But hitting command-K after opening isn’t that onerous…
No, it is not, but I suspect that’s not the way you work.
So what’s the orthodox way to work with both SD and VC ?
You have two choices with Source Code Control:
text (.applescript). This is the simplest but requires some sort of build automation to converts the .applescript file into a runnable .scpt or .app file
script bundle (.scptd). This is a directory structure of SCM compatible files. These .scptd “files” are directly runnable when checked out of your SCM, and retain full fidelity, but there are many more files that need to be managed.
THese are standard apple defined file formats and so their attributes are beyond SDs control.
Not with a .applescript file as this is a plain text file. If you want to retain syntax highlighting then you need to move to the .scptd file format - see my previous reply.
Thank you Mark. I was thinking of using .applescript because it was plain text. Now, I’m checking the files in an .scptd bundle and the only code file I am seeing is a .scpt file, which is a binary. I am not finding a plain text file version of the code that I could manage under git. Am I missing something?
You won’t. Scptd files are binary, but all the supporting information (description, etc) is stored in separate files making it possible to represent using any traditional SCM system.
Ok, so I have 3 questions:
The drawback is that .applescript files are not directly loadable into applications requiring compiled AppleScripts. There is a performance hit when compiling a .applescript file on-demand. .applescript files are fragile in the face of application terminology changes.
I consider .applescript files only suitable for sharing scripts with others and SCM because plain text is a lowest common denominator and is unlikely to be damaged in transit. I work almost exclusively with .scpt or .scptd files locally.
For me, the only time I use a .applescript file locally is when I have to save my work and the script is not in a compilable state. In these situations, .applescript is the only file format that can be used.
The nature of AppleScript makes it impossible to do 100% correct syntax highlighting without having AppleScript’s knowledge of a script and the application terminologies on which the script depends (multi-word identifiers make AS’s syntax impossible to parse without a lot of state and metadata). The effort required to re-implement all of this for the purposes of pre-compiling syntax highlighting just isn’t worth it - once opened, compilation with AS is fast and there is a dedicated key - ENTER - provided for this purpose.
We do not auto-compile .applescript files when opening them (a) to keep file opening as fast as possible, (b) to avoid launching applications the script depends on, and © to avoid user interactions resulting from property definitions (e.g. property homeFolder : choose folder)
After 20+ years of dealing with AS, the current situation is where we have settled.
It depends. For my open source stuff I use .applescript files in combination with osacompile shell scripts to generate .scpt files. Internally I use .scpt files because Xcode can be difficult and this saves effort.
I also prefer compiled scripts (.scpt or .scptd) because they are not broken when a host target application changes the terminology in its scripting interface. When decompiling a compiled script, all terminology is drawn from the most recent metadata.
Mark, thank you very much for all your answers.
I take from your answer to 3) that you don’t use VCS for most of your AS work, is that correct? Or is it that you don’t VC your source files but you do your scpt files ?
That is correct. Everything that ships with Script Debugger is kept under SCM, but all my other AS work is not.
Ok, there was a problem with eol and git configuration, I fixed it and it looks like I can work with that setting. Basically work on .applescript files for coding, testing, and then exporting to whatever when the coding is done. Excellent.
Thank you for your time.
Hey Jean-Christophe,
Don’t forget — Script Debugger itself is scriptable.
You can save a script anytime to any location as a text script:
------------------------------------------------------------------------------
set saveFolderPath to ((path to home folder as text) & "test_directory:sd_test:")
tell application "Script Debugger"
tell front document
set AppleScript's text item delimiters to "."
set docName to (text items 1 thru -2 of (get its name)) as text
set savePath to saveFolderPath & docName & ".applescript"
save it in savePath as text script
end tell
end tell
------------------------------------------------------------------------------
Or you can get the source text of a script and write it to a file.
You can put a staging address in the script header and use that to tell it where to save.
You have many choices.
If you’re going to regularly develop with .applescript files then get used to hitting Cmd-K. 
-Chris
@ccstone, thank you for the suggestion.
What do you call a “staging address” ?
What you propose is interesting. So I can develop in scpt, and when I want to commit some changes, I can just call a script to save as text, and git commit.
What I do regardless of the format is run the script regularly to see if I’m doing things wrong so I don’t need to hit Cmd+K. For that reason I’m not seeing much difference between working in .applescript and working in .scpt (except for the file status when I open it: the text one is not colored, the scpt is). Is there something else I’m missing ?
Hey Jean-Christophe,
Whatever you want it to be.
An HFS path.
A POSIX Path.
A URL.
You have much flexibility.
When I’m seriously developing a script (as opposed to goofing around) I give it a dev-header. (I have a script that makes it.)
------------------------------------------------------------------------------
# dNam: My Script Name
# dMod: 2017/03/28 01:48
# dStg: ~/Script Library/Applications/Script Debugger/
------------------------------------------------------------------------------
Now with a keystroke I can save the script to a specific location.
I have many prebuilt locations, so I don’t have to type much.
My save script also looks for a variety of characteristics in the script to be saved and automatically routes it if certain criteria are matched.
I always compile before running. It alerts me to errors and gives me visual cues to things.
I also compile often while I’m writing a script
So Cmd-K, Cmd-R is deeply recorded in muscle-memory.
-Chris
It’s the first time I hear the term “staging address”, but I understand what you mean by it.
not run, just compiled (⌘K) — running compiles first, then runs.
Well, in fact there is some sort of coloring before compile in SE/SD: the non compiled code appears in purple. That’s something, but that’s not helpful in terms of what helps the programmer write good code.
Think of it that way, what if Xcode offered syntax coloring for Objective-C or even Swift only after the code compiled properly. What would you think about the usability of Xcode ? Wouldn’t you think that’s a serious drawback ? Would anybody write any kind of serious code in Xcode if it did not offer some kind of syntax coloring before compile?
The point of syntax coloring is that it comes before the code compiles, so that you can spot errors more easily and write better code right away. There are a number of studies that confirm that it’s the practical effect of syntax coloring.
I know that Cmd+K is not onerous, but that kind of basic syntax coloring is free in other editors (I am not talking about the cost of development, obviously) and that makes work in SE and SD slightly less convenient and slightly more frustrating. It’s like you’re systematically punished for the code you’ve written wrong.
As I wrote, there are plenty of text editors that do not compile AS but still offer basic syntax coloring as you type. It is not perfect, and that’s not what I’m discussing, but it is at least some basic visual information that helps you when you code. So the feature should not just be dismissed “because we have Cmd+K”.