Wow, my new “Edit in MarsEdit” button and the corresponding shortcut are such a quality-of-life improvement in my blogging workflow.
Wow, my new “Edit in MarsEdit” button and the corresponding shortcut are such a quality-of-life improvement in my blogging workflow.
I ran into this post the other day about Script Debugger getting retired.
January 2025 marks Script Debugger’s 30th anniversary. It’s been a very long run for a two-person effort. Script Debugger began as a Classic MacOS product, survived Apple’s near-death experience, transitioned to macOS X and migrated across 4 CPU processor types. We are so grateful for the support we’ve received over these years. This support allowed us to keep working on Script Debugger much longer than we ever imagined.
Shane and I are retiring and the effort and costs associated with continuing Script Debugger’s development are too great for us to bear any longer.
I bought this app about 2-3 years ago because I was getting serious about learning AppleScript, and in a short amount of time, it became an important part of my workflow. As I mentioned, I learned AppleScript with the help of Script Debugger’s awesome live inspection feature.
Since then, I have used this app to build many scripts that I use in my everyday workflow.
I don’t know the current state of AppleScript inside Apple, but I know that the difference between Script Debugger and Script Editor is night and day. Script Debugger should be part of the system, which is why I feel sad that another great Mac app, especially one with such a long history, is getting retired.
In June 2025, Script Debugger will no longer be offered for sale and all support and maintenance will cease.
At this time, Script Debugger will become a free download. Links to all versions of Script Debugger back to 5.0 will be posted, along with registration numbers that can be used to activate the software. These free versions of Script Debugger will be provided as-is and without any maintenance or support.
Currently, the developers plan to leave it as is. The problem with this approach is that any future macOS update could break Script Debugger. It’s not like 1Password 7, which, after years, I still keep around because I’m not going to migrate to their stupid Electron app. Script Debugger is a complex beast, so any new Windows Vista-style “security” dialog could kill it in an upcoming version. And boy, Apple has been really into “Cancel or Allow” lately.
Will Script Debugger become an open-source project? No. Unfortunately, there are portions of the Script Debugger source code we do not have the right to release.
I’m not sure how the app could be saved. I created a topic on MPU to let people know about it. Open-sourcing will not work since there are licensing issues, so the last resort is for someone to buy it. Or maybe some people in the Macscripter.net community could take care of it as Late Night Software “contractors.”
I don’t know yet, but it’ll be pretty sad the day when Script Debugger stops working.
Just an aside: it makes me wonder why we have Emacs and Vim still around alive and well…
I updated my Reminders/Hookmark integration script recently to make it faster on Sonoma. I also made sure that I have a “New Item” part too, so I can create reminders directly from Hookmark.
The “Get Address” script uses the backing SQLite database to find the ID of the selected reminder by title.
There are some caveats to keep in mind:
remindersDatabasePath
property with the proper database path which is different for everyone.Here are the scripts updated for Sonoma:
Get Address
use AppleScript version "2.4" -- Yosemite (10.10) or later use scripting additions -- Replace this with your Reminders database path. property remindersDatabasePath : "/Users/yourusername/Library/Group Containers/group.com.apple.reminders/Container_v1/Stores/Data-some-UUID.sqlite" tell application "System Events" tell its application process "Reminders" tell its window "Reminders" tell its splitter group 1 tell its UI element 3 tell its UI element 2 tell its UI element 1 set reminderOutline to first UI element whose selected of UI element 1 is true set theReminderName to value of UI element 2 of UI element 1 of UI element 1 of reminderOutline end tell end tell end tell end tell end tell end tell end tell set theSQLCommand to "/usr/bin/sqlite3 \"" & remindersDatabasePath & "\" \"SELECT ZCKIDENTIFIER from ZREMCDREMINDER WHERE ZTITLE = '" & theReminderName & "'\"" set theReminderIdentifier to do shell script theSQLCommand set theURL to "x-apple-reminderkit://REMCDReminder/" & theReminderIdentifier return "[" & theReminderName & "](" & theURL & ")"
New Item (this one can be a bit slow unfortunately)
tell application "Reminders" set theName to "$title" set theBody to "$user_link" set theReminder to make new reminder with properties {name:theName, body:theBody} set theReminderURL to the id of theReminder set theReminderURL to do shell script "echo \"" & theReminderURL & "\"|sed 's/x-apple-reminder:\\/\\//x-apple-reminderkit:\\/\\/REMCDReminder\\//g'" activate end tell theReminderURL
I haven’t tested these on earlier systems.
I just started using Sonar which is a new GitHub/GitLab issue tracker client available as a TestFlight beta.
I found that the app has a URL scheme, so asked developers if it was implemented, and they were kind enough to give me a brief documentation, just enough to create a starter script for myself.
I was thinking about making a more advanced GTD system in Numbers other than just using Reminders in macOS. This post lays out this idea in more detail.
We can store next actions of a GTD system in Apple Numbers by creating two tables for “Next Actions” and “Projects”.
Writing an AppleScript for syncing with Reminders should be possible.
I figured out how to get the built-in Apple Notes URL for the selected note in Hookmark (or in any app that can run Apple Scripts), so I can replace the default Hookmark script, which is a bit cumbersome.
I have a detailed write-up about the script’s inner workings in the Hookmark forums. It can be helpful even if you don’t use Hookmark. You can modify the script to copy the URL to the clipboard.
I was in a Tinderbox Meetup last week, which was more about Hook than Tinderbox. I’m not a Tinderbox user, but I’m interested in how other people use their tools.
In the middle of the call, somebody had a question about Hook bookmarks. More specifically, can Hook archive its bookmarks as archive.org does with websites in general? Well there is no feature like that in Hook, and to be honest, doesn’t even need to be, because Hook has great Apple Script integration, so we can query bookmarks from its database.
In conjunction with DEVONthink, we can archive our bookmarks from Hook and save them as Pinboard does. I made a script for this a while back and it’s really helpful. It runs once a week, archives all websites from my Hook database into DEVONthink.
First, download the script from here.
The scripts collect everything into one group in DEVONthink, so you have to create one where the archive can be stored. I would advise a new database even if you don’t have something similar already.
Open the script you downloaded. You’ll see two lines at the top of the file.
set webArchiveDatabaseUUID to "databaseUUID" set hookedWebsitesGroupUUID to "groupdUUID"
You have to replace the databaseUUID
and the groupdUUID
part with the UUID of the database and group from DEVONthink. To do this, open DEVONthink, ⌃click on the database in the sidebar, and pick “Copy Item Link”.
Now, replace databaseUUID
, with the link you copied. You’ll see something like this.
set webArchiveDatabaseUUID to "x-devonthink-item://CA3A9072-0650-4AF3-A608-1786F9D1A98D" set hookedWebsitesGroupUUID to "groupdUUID"
Now, remove the x-devonthink-item://
part, so the top of the script should look like this.
set webArchiveDatabaseUUID to "CA3A9072-0650-4AF3-A608-1786F9D1A98D" set hookedWebsitesGroupUUID to "groupdUUID"
Go back to DEVONthink and copy the group’s link from the same database (it is important to keep the group in the same database) by ⌃clicking on it and picking “Copy Item Link” again.
Replace groupdUUID
with the copied link in the script again.
set webArchiveDatabaseUUID to "CA3A9072-0650-4AF3-A608-1786F9D1A98D" set hookedWebsitesGroupUUID to "x-devonthink-item://B6C2C659-5682-45B5-8D59-107A641F8C2D"
Remove the x-devonthink-item://
part and then save your changes. The top of the script should look something like this now.
set webArchiveDatabaseUUID to "CA3A9072-0650-4AF3-A608-1786F9D1A98D" set hookedWebsitesGroupUUID to "B6C2C659-5682-45B5-8D59-107A641F8C2D"
Now comes the fun part. You can run the script and DEVONthink will start downloading your Hook bookmarks into the group you choose.
The first run can take a while depending on the size of your Hook database. Subsequent runs should be faster since the script downloads only newly added bookmarks.
It is important to know that the script doesn’t sync Hook and DEVONthink, deleted bookmarks from Hook will still be present in DEVONthink.
Also good to know, if you want to archive sites behind a login, you have to sign-in in DEVONthink before you run the script.
I keep this script in the ~/Libary/Scripts/Applications/DEVONthink 3
folder, so it’s available from the script menu in macOS – or in my case, from FastScripts. This way, you can run the script manually from DEVONthink.
You can even make it run automatically. If you use FastScripts, you can create a new DEVONthink reminder on the group you created to store Hook’s bookmarks and set it to run an Apple Script like this every week.
on performReminder(theRecord) tell application "FastScripts" set scriptItem to first script item whose name is "Archive Hook Bookmarks" tell scriptItem to invoke end tell end performReminder
If you want to run it outside of DEVONthink, you can use for example Lingon, which makes it possible to run any Apple Script in the background daily, weekly, monthly, or whatever interval you want.