Request for AppleScript

Now that Drafts (19) has begun to support AppleScript I would like to request a specific capability that would allow my macOS app to support Drafts. This is support for 3rd party apps to run AppleScript against Drafts (not internal actions…)

Here’s the pseudo code of what I could use:
tell application “Drafts” to return the permalink of the current draft

This is based on examining the .sdef that was included in the Drafts update.
permalink (text, r/o) : The URL of the draft.

Thanks for Drafts!!

It is planned, but this release is just a first step.


1 Like

This morning I woke up with one the weirdest solution for a long time to a peculiar problem and found out:

”The solution was embedded in the error!” :crazy_face: Nevertheless, I would appreciate if there are better alternatives.

I’ve had a very efficient solution for years utilizing Alfred:

  • Doubletap-⌘ creates a new Draft prefilled with the fundamental questions (from Kipling but in the following order): When, Where, How, Who, Why and What.

Now, when Drafts has started to support AppleScript and CSS templates I thought I would like to extend that solution utilizing Location Helper (since this precedes the Draft but a template and an action could be another option) and other adaptations of a Markdown content with some footnotes and so on.

This AppleScript gives me the new Draft with Markdown in memo and a tag:

set myDraft to make new draft with properties {content:memo, tags:“memo”}

However, that Draft was not then opened for direct access and it seemed impossible to get various properties from myDraft, s.a. permalink, UUID and more. Then I suddenly realized the information was in the error string itself! So I simply wrapped my attempt in a try structure with on error str and then extracted the UUID:

set myID to characters 2 thru -3 of ( last text item of str)
set AppleScript’s text item delimiters to “”
set myID to myID as text

Then it was straightforward to open that Draft:

open location “drafts5://x-callback-url/open?uuid=” & myID

This works like charm but is not so esthetically pleasing as e.g.

set myID to permalink of myDraft

Am I missing some specific syntax that actually should work in the more usual way?

(Until then this may be a tip for other people having the same problem.)

Of course, this is even simpler but a little more direct (recognizing that UUID is delimited by double quotes).

set AppleScript’s text item delimiters to quote
set myID to (text item 2 of str)
open location “drafts5://x-callback-url/open?uuid=” & myID

Also, after that the way is wide open to “Open in New Window” and set to “Float on top” as I usually are working on other thing when these more or less sudden interruptions occur but Drafts lets me stay on top—literally.

Take a closer look at the URL scheme options. Particularly the one for creating drafts. There are options to set for content and tags.

For example, what happens if you trigger the opening of this URL?


Also, don’t forget you can trigger a native Drafts action via the URL scheme which opens up a lot of options for you until the AppleScript support gets to the point where external automation is broader.

Thanks, yes that was in fact my old solution and is still an option.

The reason I started to experiment with AppleScript was that I had to compile a lot of Markdown information (extracted from other AppleScript) and just tried to avoid to URL encode everything which I haven’t been very successful doing but from your advice I also tried this solution which works nicely!

set memo to do shell script ("/usr/local/bin/jq -s -R -r @uri <<< ‘" & memo & "’") – URL encoding
set newDraft to “drafts5://create?text=” & memo & “&tag=memo”
open location newDraft

It seem to me a combination of the Drafts URL scheme and AppleScript can give me anything I have wanted so far. At least I now know how I can get the UUID for a created draft from AppleScript even though that is probably not the recommended method which can be changed later when more support is available.

On problem now is that Drafts crashes from time to time and the solution is somewhat shaky especially when returning to Drafts after the new draft was created. “Most of the time” it seems to work though.

Therefore, I will also look into a native Drafts action via the URL scheme later which I also had in mind previously.

If you are having stability problems, that would be worth a support e-mail. If you can reliably reproduce your issue with an example, Greg always appreciates having the details to examine.

If encoding is your main sticking point, and if you are using files, put the files in the Drafts import inbox directory. If you have consistent tags, that would be an easy choice to standardise while you import. You can also drag and drop files in, and then you would just need to set the tags afterwards.

If you are not working with files, you could dump your content to the clipboard and have the URL scheme call an action that creates a new draft from the current clipboard, parsing out any tags from say the first line - allowing you to deal with multiple different tags, or you could have the tags passed as parameters to the action in the URL scheme.

Thanks for that tip, too. It might be an option even though the encoding works fine now.

One of the shortest sequences that seems to cause a crash is the following:

  1. Create new draft with the URL scheme (from my Alfred workflow, AppleScript, triggered by doubletap-⌘).
  2. ⌘W to close the newly created draft (which is now a separate floating window) or ⌘S and then closing the floating window.
  3. Trying to click drafts in the navigation bar.

Crashes ~3 out of 4 times.

However, I’m about to change computer (with Catalina) very soon so will not delve into this too much.