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.
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.
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?
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.
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.
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.
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
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.
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 ?
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”.