iOS remains a cesspool of annoyance, but I can’t leave

I’ve been using iPhones since the very first one; I had one in my hot little hands a mere 2 weeks after it debuted. So I’ve seen nearly every shitshow come and go. I have an extremely high confidence that most egregious problems will be resolved, because they always have been, and it remains in Apple’s best interest to continue to fix the big problems.

The small problems, however, remain from release to release. I’m not sure they’ll get around to fixing them. Or, possibly, I’m “lucky” and the only person in the world with these problems.

Continue reading “iOS remains a cesspool of annoyance, but I can’t leave”

Applescript is unrelenting garbage, an ongoing series

From the docs for the “Standard Suite” command make:

Screen Shot 2018-03-07 at 2.43.23 PM.png

 

As written this says that new is a required, optional keyword to the make command.

The intention/actual meaning is that the type class is a required argument to the make command, and use of the new keyword is optional.

Also, for what it’s worth, with data is required (in BBEdit anyway), which another part of the documentation says is optional.

A brief, painful attempt to understand JSA

JSA is “JavaScript for Automation”, aka Apples attempt to embed JavaScriptCore into their Apple Event model.

The use case here is, roughly, “I know JavaScript and [love|like|tolerate] it, but I cannot under any circumstances be arsed to do anything useful in AppleScript, because AppleScript is easily one of the worst software platforms ever created by man”.

Seriously, AppleScript is extremely bad. I have in my life encountered a few people who loved it; and nearly 100% of them are not work-a-day programmers. AppleScript is purpose-built to confuse, annoy, and frustrate people who can chew through languages like Swift with little effort.

(I’m not trying to start a “you’re not a real programmer” thing; if you write a program – any program – you’re a real programmer! I’m just saying that the norms AppleScript adheres to are typically diametrically opposed the stuff we work-a-day programmers have deeply, deeply internalized as “normal”.)

Anyway! I decided rather than replace a bunch of light switches my wife has decided are no logner aesthetically pleasing, I thought I’d spend the morning trying to hack on some JSA. After all: how hard can it be? It’s JavaScript and I know JavaScript, and I have once or twice managed to fumble around with AppleScript until I accomplished something useful.

I can sum up the morning with the phrase, “Oh, for fuck’s sake”.

Continue reading “A brief, painful attempt to understand JSA”

Missing features in the iOS Activity app

I’m sort of amazed we’ve made it as far as we have without these two features being built in:

Sick days. Sometimes we get sick! It would be pretty great to not lose a streak because I have a really bad cold.

Rest days. This is the big one. One day a week, it would be nice if my calorie goal could automatically be a little lower. It’s very common for workout programs to have a day per week that is to be at a lower intensity.

There’s almost certainly apps that can incorporate this somehow – although I’m not sure how to reset the calorie goal for a single day, one assumes there’s an API for it.

So why don’t we replace AppleScript?

So AppleScript sucks. What’s the alterative?

I don’t get why Apple hasn’t seriously entertained a “next generation” scripting engine, in particular one based on JavaScript. All the things are there:

There’s the “canonical” JavaScript OSA component but it doesn’t fit the criteria: it uses Spidermonkey, not Squirrelfish/JavaScriptCore. Still, its API is pretty spot-on (since it’s an OSA component). It’s also pretty old.

JSTalk is another contender. It’s sort of the opposite number of the JavaScript OSA: it uses entirely modern, native components – stuff Apple almost literally has laying around – but does not feature an OSA-compatible API (as near as I can tell anyway). But, it’s modern and very friendly with Cocoa.

The sweet spot is the fusion of the two; the “already works on top of an OSA layer” of the former and the “all the modern stuff” of the latter.

Someone at Apple please make this happen! Make scripting the Mac awesome.

An example of why Applescript is utterly awful and must be replaced

A while ago, I attempted to resolve the problem in Safari’s Delibar extension, wherein it can’t do what the Chrome extension can: automatically put the selected text into the ‘notes’ field.

I failed.

In part I failed because of Safari, and the way it structures extensions. Briefly, Safari uses a sort of separation-of-concerns model, so what a particular piece of an extension can access varies. Getting the selection is really hard because you need to use proxying and messaging to communicate between the current page, the extension’s “page”, and any resources.

I gave up because it sucked and wasn’t fun.

I had another thought: use Applescript to get the selection and pass it to the Delibar app itself! GENIUS!

The tl;dr here is “Delibar isn’t scriptable” so none of this matters, anyway.

Safari’s Applescript dictionary doesn’t include the term “selection”. To the best of my knowledge, you cannot use Applescript to get the selection of the current tab. Oh ….. kay.

So, the next logical step is to use JavaScript, because I know it has the ability to get the selection AND I know that there is a ‘do JavaScript’ command in AppleScript for Safari. Now we’re cooking!

Here’s the relevant bits from the dictionary:

 

do JavaScript (verb) Applies a string of JavaScript code to a document.

 

and the example:

 

set theResult to do JavaScript unicode text ¬ in tab

 

Makes sense, right? Sure. So you’d pretty much imagine that it works just like this:

tell application "Safari"
    set selectedText to (do JavaScript “window.getSelection()” in current tab of window 1)
end tell

Always returned null. Always. I then tried hundreds of combinations of more-or-less JavaScript, including:

  • adding a return
  • wrapping it in an anonymous function
  • using document instead of window
  • banging my head against the desk and cursing myself for ever having these sorts of thoughts After lots of searching, I discovered the completely obvious answer:

    do JavaScript “(”+getSelection())”

That’s a double-quote, left paren, single quote, single quote, plus, then the function and a closing quote.

Of course. Completely obvious. Note that removing the single quotes and concatenation operator doesn’t work. So “(foo())” doesn’t work, but “(”+foo())” does. I found two places that say it does work, but I can’t make it happen in the latest Lion and Safari.

How the hell do you even arrive at that as a logical place. And how do you expect regular people, ostensibly the target market for Applescript, to arrive at that conclusion?

Applescript is goddamned awful.

In which I play around with Vico

For many the holy grail of text editors is Textmate. In a very short time it became an indispensable tool for many, many programmers and sysadmins.

Then it stagnated horribly, it gets updated perhaps once per year (and then only to keep it running on the new OS release), and god forbid you find a bug: it will probably never be fixed.

(As I write this there is an alpha promised by Xmas. Many are understandably cynical about this.)

A bunch of projects started up to fill the vacuum created by TM2’s vaporware status. Without sounding too negative on what was an incredible amount of work, they’ve managed to re-implement much of TM1 in the time it took to get TM2 to alpha status. That said making your app compatible with the huge TM1 ecosystem (and what may be the TM2 ecosystem) is an obvious good design call.

Anyway, the two I had immediate access to are Vico and Sublime Text 2. More on Sublime Text 2 later.

To reduce it to the simplest description, Vico is a vi implementation in Cocoa (or at any rate, Mac-native) that is mostly TM-compatible (themes and bundles).

(Also note: I’m sort of unfairly conflating vi and vim here. Pedants, don’t freak out. Hopefully you’ll get what I mean.)

Whether or not you consider vi’s modal editing a plus or minus is not really even worth debating. If you don’t like modal editing, don’t bother to even try any modal editor.

Vico supports a pretty finite subset of vi commands, but enough that you’ll preserve basic muscle-memory when editing. As near as I can tell, commands aren’t as “composable” as a real vi, but that’s where the bundles take over.

Vico supports a subset of TM bundles, so you can probably drop in some functionality that would normally be done with vim macros or scripts.

You can also “drive” Vico’s functionality with built-in scripting using the Nu language. Nu is the (perhaps unholy?) fusion of LISP and Objective-C/Cocoa.  And example of using Nu scripting to perform an editor task (automatically hard-wrapping text in this case) is on the Vico blog.

Is that any better than Vim script, or ELisp? I dunno. Vico seems like too much mashed together. It’s in a weird place: if you’re determined to retain modal editing, why not just use MacVim? Well, MacVim is … not so much ugly as plain. So, assuming the creator can keep up with the state of the art enough to keep the users happy, it’s a nice way to appeal to modal editor junkies who somehow don’t fancy MacVim.

But what of the people coming from TM? Isn’t modal editing a huge change, even if it lets them keep some of their workflow? OK, you’re addicted to some set of TM features, but hopping into the world of modal editing seems like as big a jump as switching to some other editor (BBEdit, etc).

Anyway, Vico is an interesting project and I sincerely hope it stays around for a long time: I’m hugely in favor of taking “venerable” Unix concepts and wrapping them in modern clothes.