Easily launch scripts from Spotlight

I've been advertising AppleScript a lot here. Automating a task is something, but easy access to that automation is quite important too.

Since I try to stick to Apple solutions and free software* I prefer using Spotlight instead of all the smart launchers that we have for macOS.

What I do is that I call my script names that are easy to call first in Spotlight. A few screenshots speak louder than words so here we are:

The series that start with ">" usually is scripts that I use to open something.

See how just typing ">" suggests ">BB". That ">BB" is what I use to open the files selected in Finder with BBEdit.

The one below is ">Tedit", short for "TextEdit" and opens selected files in TextEdit, etc.

If I type "c" after ">", I get the following list of choices. ">command" is to launch an arbitrary command in Terminal, ">Capture" is to use org capture in Emacs (see here and here for more information) and ">cd" just opens a Terminal tab on the front Finder window, or selected Finder folder.

When I use "<" to initiate the search, I get a different list. That series is for scripts that usually act by themselves. "<text file" creates a text file in the front Finder window and proposes to open it in BBEdit for editing, "<facturation" is an invoicing script for the job selected in Finder, "<job" is a job managing script that creates a job hierarchy in Finder based on a mail, along with an event in calendar, and then "<xls2tmx" is a TMX converter for multicolumn Excel reference data (I'll publish it when it's more polished, but creating XML data with AppleScript is documented here).

I have a few more scripts (a dozen) that I routinely call with Spotlight, which I find totally sufficient for my needs.

As you know, hitting Command+Enter when you have a selection in Spotlight is a way to reveal that selection in the Finder if it is available. So when I want to edit a script, I start by calling it in Spotlight, I hit Command+Enter when it is selected and then I call ">SEditor" (Script Editor) or ">debugger" (Script Debugger) on the selection, to open it with the appropriate application...


* Ok, I do have BBEdit, Microsoft Office and Illustrator... And maybe a few others...

Open a file in your editor of choice

[Update]
Chris Stone has a nice follow-up on the BBEdit user forum.

---

You know how it is. You double-click on a file thinking it will open in the application that you're working with at the moment and you forget that the file type was associated with a different application...

Back to Finder, right-click on the file, select "Open with..." and you're good. But mousing around macOS can be tedious at times so here is a simple script that I was pretty much given by an ASUL co-lister and that I barely had to adapt to my workflow to make it more general.

property targetApplication : "BBEdit"

tell application "Finder" to set mySelectionList to selection as alias list

if length of mySelectionList = 0 then error "No files were selected in the Finder!"

tell application targetApplication

repeat with myFile in mySelectionList

open myFile

end repeat

activate

end tell

You notice right away that the only reference to the opening application is in the first line. You can change the application name to anything you want and have multiple copies of the script, one for each application, with an appropriate name so that you can open any file with any supporting application you want.


Here is the exact same code for TextEdit:

property targetApplication : "TextEdit"

tell application "Finder" to set mySelectionList to selection as alias list

if length of mySelectionList = 0 then error "No files were selected in the Finder!"

tell application targetApplication

repeat with myFile in mySelectionList

open myFile

end repeat

activate

end tell

The same for Script Editor:

property targetApplication : "Script Editor"

tell application "Finder" to set mySelectionList to selection as alias list

if length of mySelectionList = 0 then error "No files were selected in the Finder!"

tell application targetApplication

repeat with myFile in mySelectionList

open myFile

end repeat

activate

end tell

The same for Script Debugger:

property targetApplication : "Script Debugger"

tell application "Finder" to set mySelectionList to selection as alias list

if length of mySelectionList = 0 then error "No files were selected in the Finder!"

tell application targetApplication

repeat with myFile in mySelectionList

open myFile

end repeat

activate

end tell

The same for Word:

property targetApplication : "Microsoft Word"

tell application "Finder" to set mySelectionList to selection as alias list

if length of mySelectionList = 0 then error "No files were selected in the Finder!"

tell application targetApplication

repeat with myFile in mySelectionList

open myFile

end repeat

activate

end tell

You get the drift.

Some applications don't work that way, so here is the code for Emacs.app:

use AppleScript version "2.4" -- Yosemite (10.10) or later

use scripting additions

tell application "Finder" to set fileSelection to selection as alias list

try

tell application "System Events" to tell process "Emacs" to set frontmost to true

on error

tell application "/Users/suzume/Documents/Code/emacs/nextstep/Emacs.app"

activate

delay 1

end tell

end try

# return

repeat with selectedFile in fileSelection

set the clipboard to (POSIX path of selectedFile)

tell application "/Users/suzume/Documents/Code/emacs/nextstep/Emacs.app"

tell application "System Events"

delay 0.5

keystroke "x" using {control down}

keystroke "f" using {control down}

keystroke "a" using {control down}

keystroke "v" using {command down}

keystroke "k" using {control down}

key code 36 # Escape

delay 0.1

end tell

end tell

end repeat

The code makes use of UI scripting because Emacs does not support Applescript, but it works just as well.

What you do now, is create one script for each application you want to open your files with, save the script with a name that Spotlight will easily call first (something like ">BB" for opening in BBedit) and you're done!

Thank you Chris Stone on ASUL (and all the others) for your help !

Wordpress site translation (1) install a local copy

I'm currently working on 2 WP sites. One is the sub-site of a world-wide IT organization, the other one is the main site of a local business. I had forgotten how site localization can be a pain, so here is a summary of the solutions I'm using for the 2 sites.

The main issue with any kind of site (be it WP or any other system) is access rights. If you don't have full access rights (or only limited access), you can only do what the client allows you to do. Depending of the l10n savviness of the client, that can be a lot or very little.

So let's say that you work directly for the client and you have full access rights to the site.

First you don't want to work directly on the site. You want to install the site on your machine and have it run locally to be able to see all your changes and validate them before you reproduce them online.

Also, you want to be able to manage your changes and know exactly what was that change your made for. You want to have granular control of all the modifications and for that you'll need a version control system. That way you can revert any modification any time you want.

1. Follow the instructions here to install a "blank" WP site locally and to be able to run it: https://codex.wordpress.org/Installing_WordPress_Locally_on_Your_Mac_With_MAMP
2. (Install and) Use the "All-in-One WP Migration" plugin on the online site to export all the data (an FTP download only won't work, there are databases, etc. that you can't access from FTP)
3. Use that same plugin on the local site to import the site
4. Now you have a copy of your online site running locally. Changes that you'll do locally will be live right away so that you can test them. They will not affect the online site.
5. To have granular control of your modifications, use git to create a version control repository for your site: enter the root of your site and run "git init", add all the files to the repository.
   
   • A few links to get up to speed with git:
   • https://xkcd.com/1597/
   • https://www.sitepoint.com/introduction-to-git-1/
   • https://git-scm.com/docs/gittutorial
6. You need a robust backup system. Something that does everything automatically so that you don't loose too much data (or any data at all) in case of problem. Time Machine is good but don't hesitate to use something more sophisticated.
7. You can now start working on the site localization.

WP is a mess when it comes to translating a whole site. There are no integrated mechanisms to access all the localizable parts: you have to use plugins to create the l10n infrastructure, then plugins to export the theme strings, then whateverelse to actually access the textual contents of the site.

I'll write more later about the second phase of the l10n: the actual translation process.