It’s simply not feasible with AppleScript, for several reasons (the use of spaces, quirks of the compiler, etc). If you want to see what happens when you try, have a look at Xcode. You get things like “missing value” appearing with the two words styled differently. It not only gets the styling wrong – it’s likely to mislead the user rather than help them.
I’m sorry, I don’t understand what you wrote. I thought Xcode was not able to compile AS ?
That’s right. But it does attempt AS syntax coloring.
Yes, there are. This forum does this as well for AppleScript code snippets. However, this formatting is not going to be 100% correct. In the worst case, failed AppleScript code formatting gives an incorrect interpretation of the meaning of a statement. This would be unacceptable within Script Debugger where 100% correct presentation of source code and state is required.
As I said above, we have reasons for not auto-compile text scripts when they are opened. We can provide syntax highlighting when opening compiled (binary) scripts because they must be decompiled into their source textual form for display and this decompilation process conveniently provides authoritative syntax highlighting.
AppleScript is fundamentally unlike the Algol-derived languages you are comparing it with (C, C++, Objective-C, Swift, Ruby, Python, etc.). Its syntax is not deterministic - it depends on the terminology provided by the applications the script communicates with. The use of multi-word identifiers is also central to this problem.
Please, we provide the ENTER key or Command-K shortcut as a means of compiling a script. This has served us all for well over 20 years. This is one of those “if it hurts, stop doing it” moments. If syntax highlighting-on-open is critical to you, then I recommend you stop using .applescript files and move to a compiled script document format where this functionality is provided.
For this and lots of other reasons, I personally rarely use the .applescript file format. I view it as a document interchange format, not an editing format. But that is just me. Everyone will select a file format based on their own needs and tastes.
1 Like
Sorry, I am not complaining about the issue. I just want to understand why it is technically not possible. I am totally satisfied with @ccstone’s suggestion and that’s what I’ll implement, but I’m still curious about the fundamental reasons why basic syntax coloring is not present.
The syntax coloring you get from the AppleScript compiler (which is the same for Script Debugger, Script Editor, Smile and any other appleScript editing environment) is definitive. While there may be other ways to mimic or match the look of the AppleScript compiler result there are several specific reasons it’s not practical or reasonable to expect.
First any application can define it’s own keywords in appleScript. An accurate depiction of color coding in appleScript must use the dictionary for every app referenced in the script. Otherwise there is no way to tell the difference between an application keyword and a user’s variable.
Second, is dynamic dictionaries. Several apps allow plugins, and sometimes those plugins can, when the application launches, add terms to the dictionary. So not only is access needed to the dictionary to determine precise syntax coloring, but the applications must also be launched.
You can copy and paste a script into this forum with the ```appleScript flag, and see how close you can get to syntax coloring. It looks similar to actual compiled appleScript, but if you look closely you’ll see numerous differences.
The final reason is practicality. Mark could probably do a raw text compiler to make formatted text look exactly like a compiled script, but why duplicate something that Apple has mastered and is literally only a click away with any script?
If you open raw text in SD and need to see colored syntax just click the compile button.
I think that’s already been answered by others, but let me try again.
The pretty-printed, syntax-highlighted text you see when you compile an AppleScript in Script Editor or SD is not produced by the editor itself. It’s actually produced by the AppleScript scripting component. The component turns the words in the editor into byte code, then decompiles that to return the formatted, human-readable, text. How that turns out depends, as Mark has said, on the exact context of the terms in the script, and that cannot be determined until compile time (why not? Because, among other things, it depends on examining the dictionaries of any targets mentioned in the script).
The syntax-highlighted colouring you see in this forum, in Xcode and in certain other text-editors on uncompiled text is achieved by the editor. In basic terms, it is categorising what words it can into different classes and applying the same formatting to them. It is not the same and cannot be the same as that produced by the compiler - at best it can be a good-guess.
It would be confusing and misleading to have two different syntax-colouring schemes in SD - one that was the editor’s inevitably inaccurate guess and one that was the actual, true compiler’s formatted script.
1 Like
Hey Jean-Christophe,
Editors that make AppleScript highlighting available have a language module written by a person. It likely has ONLY the core AppleScript terminology you’d find in the Applescript Language Guide in it.
That means all app-specific and osax-specific terminology won’t be properly highlighted using such a scheme.
This is one reason so many programmers dislike AppleScript. Every time you turn around there’s different terminology that isn’t documented anywhere that you have to figure out for yourself.
And this is yet another reason why Script Debugger is so indispensable, because it makes figuring that terminology out easier.
Sometimes you just can’t figure out how terminology works without useful examples, and people who write scriptable apps seldom provide a good array of examples.
-Chris
That’s done by the editor and you can have it any colour you like in SD or SE (you set the colour in the Preferences). All it’s doing is colouring the entire string contained in the view. I have mine a rather different shade of purple. 
I believe the category is New Text (uncompiled).
-Chris
I totally understand now where SD’s syntax coloring comes from. Thank you @sphil for making that even clearer. 
Now, you all seem focus on getting the exact orthodox coloring otherwise people get confused etc. But that otherwise is not true. I do understand that a lot of people here do very exotic things with SD that cannot possible be covered by editor based coloring, but the vast majority of scripters don’t, and stick to basic syntax and need visual contrast as they type before they compile to just see what they type.
Now, I am not requesting this feature, or even suggesting that SD is sub-par because it doesn’t offer this feature, so let’s put SD out of the equation right now, and let’s agree, if you please, that editor based syntax coloring, even if not 100% accurate, is a huge plus for coders in general .
And yes, I promise I’ll cmd+k my code.
FWIW, I strongly disagree. Well, I’d probably accept 99.99%.
1 Like
I accept this, and this is why we provide “editor” style syntax highlighting here on this forum. Its vastly better than nothing.
This problem is not limited to esoteric scripts. An example is when a simplistic syntax highlighter suggests that a token is a variable name instead of an application-defined term. Another example is when a simplistic syntax highlighter suggests a token is an AppleScript reserved word (e.g. when, etc.) when in fact its part of an application defined term or a user defined variable or property name.
Consider this little example. What is the groups token?
name of groups -- groups is a variable
tell application "Contacts"
name of groups -- groups is a reserved word defined by the Contacts application
end tell
AppleScript draws this distinction:
Here’s another example:
set x to {groups:"Something"}
groups of x -- gets the groups property of x
tell application "Contacts"
groups of x -- tries to get the groups collection of x - and fails
end tell
AppleScript gives you a clue by highlighting groups as an application identifier within the tell block:
I know this all may seem like I’m being finicky, but AppleScript’s rules for interpreting identifiers and scope are not always obvious. Syntax highlighting is sometimes the only clue you get as to how AppleScript is treating your source code - its simply not clear from reading the text of a script.
Thankfully, its easy enough to copy-paste the code into SD/SE, compile it and see the truth. And when simply scanning the text of a script, all this may not matter, but when the time comes to understand what is actually happening in a script, it really does.
1 Like
Fascinating stuff Really thank you for going that far in the explanations.
So basically, the forum editor does not have access to the Contacts dictionary and thus can’t possibly know that the “groups” within a “Contacts” tell block is something pertaining to Contacts, a class in this case.
But on the machine, the Contacts sdef file is XML and is parsable by anything so for a program to understand that within a Contacts tell block “groups” is a class, it would be enough (excuse the term if I make it sound like it’s easy ) to look for Contacts in the path, check it’s sdef file and color groups as a class instead of as just a variable. Is that assessment correct ?
If it is, implementing that would bring major improvements to “simple” AS syntax coloring that is currently not available anywhere but in SE/SD/Smile. Now, it still would not be the 99.99% that @ShaneStanley considers a deal breaker, but it would get reasonably closer, wouldn’t it?
You might want to re-read Ed’s post above where he addresses why simply reading the dictionary is not sufficient.
I’m not saying it’s sufficient, I’m saying that it’s better than not parsing the dictionaries. And I do understand now that it’s a very complex issue. Thank you all for all your explanations.
Not to complicate a seemingly resolved issue, but when a compiled script is saved SD does create a Text-RTF file complete with syntax coloring, and it is possible to access that file via a script.
Is the coloring in that file accurate?
Would that suffice for Git-hub?
Yes, this syntax highlighting is 100% correct.
The problem with rtf is that as far as git and other vcs are concerned, the text part of the file includes all the rtf code and rtf is ugly. So for code version control, that would not work.
For ex, the code above would look like this as far a git is concerned:
{\rtf1\ansi\ansicpg1252\cocoartf1504\cocoasubrtf820
{\fonttbl\f0\fnil\fcharset0 Verdana;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;\red108\green5\blue211;\red0\green0\blue255;
\red76\green78\blue78;\red64\green128\blue0;}
{\*\expandedcolortbl;;\csgenericrgb\c0\c0\c0;\csgenericrgb\c42337\c1841\c82833;\csgenericrgb\c0\c0\c100000;
\csgenericrgb\c29999\c30457\c30457;\csgenericrgb\c25000\c50001\c0;}
\deftab480
\pard\pardeftab480\slleading40\pardirnatural\partightenfactor0
\f0\b\fs28 \cf2 use
\b0 \cf3 AppleScript\cf2 \cf4 version\cf2 "2.4" \cf5 -- Yosemite (10.10) or later\cf2 \
\b use
\b0
\i \cf4 scripting additions
\i0 \cf2 \
\
\cf3 name\cf2
\b of
\b0 \cf6 groups\cf2 \cf5 -- groups is a variable\cf2 \
\
\b tell
\b0
\i \cf4 application
\i0 \cf2 "Contacts"\
\cf3 name\cf2
\b of
\b0 \cf6 groups\cf2 \cf5 -- groups is a reserved word defined by the Contacts application\cf2 \
\b end
\b0
\b tell}