mac and iphone

org-mode and iOS (again)

After Sunday’s jaunt into converting my Things todos into an org-mode file, I re-fixated on MobileOrg.

Here’s the thing about MobileOrg:

It thinks about your org-mode stuff pretty much the way Emacs does, which is to say that it’s pretty firmly rooted in the notion of plain text files. If you’re hoping you’ll just get a list of all your todos when you start it up, it’s going to disappoint.

Here’s another thing about MobileOrg:

It wants you to use either WebDAV or Dropbox to sync, but not in the way you might have naively thought, which would be “if I put my org mode files up on Dropbox, I’m golden.” Instead, it uses Dropbox or WebDAV to maintain a staging area that the iOS client and Emacs can push into and pull out of using sync functions on either client end. It’s a little cantankerous about this, and if you try to set things up without grokking the way it wants to work, you’ll have problems and there will be sadness.

So, I’ve got it working and I will use it as a way to consult the status of projects now and then when I’m not near my computer and I’ve remembered to push my desktop content into the Dropbox staging area. It’s not earth-shattering.

One sort of useful thing that I started playing around with, though, was an iOS app called Drafts. On its face, Drafts is a ridiculously simple text editor. When you start it up — which it does very quickly — it just sits there staring at you. You type stuff in it, maybe switch away from the app, and come back to see that your stuff has been archived and there’s another blank screen staring at you.

Drafts sort of isn’t really about plain text the way a notes app typically is. It’s actually about creating text-based workflows that shuttle your text off to other services for processing. It comes with a default set of actions that make its mission clear. Given a few lines of text in a Drafts buffer, you can:

  • Tweet it
  • Send it to Facebook
  • Add it to a journal note in Evernote
  • Send it as a text message
  • Save it as a file in Google Drive
  • Append it to a file in Dropbox
  • Turn it into an email message
  • Render it as Markdown into HTML then turn it into a rich text email message

Drafts is extensible, so that’s just what it does out of the box. There are hundreds of workflows for all sorts of things based around sending things to web services or processing them in-app via JavaScript, and you can write your own in-app. All your workflows sync via iCloud, and you can customize the action menus to suit what you need to do. Drafts also includes a basic templating system, so when you write actions, simple placeholders like [[date]] expand to the current date, [[clipboard]] expands to the current system clipboard, and [[date|%Y-%m-%d]] does what you’d expect if you know how strftime works.

If you have no patience for setting up MobileOrg, or don’t think you’d really want it, you can use Drafts to append stuff to your org files stored in Dropbox way more quickly than if you were to use the Dropbox app to navigate to them and edit them. I made an action that takes the text in a Drafts buffer and appends it to my file as a timestamped todo. Using the templating placeholders for lightweight guardrails makes it easier to not screw up org mode’s simple but special-character-laden syntax. Here’s the one I set up:

 * TODO: [[title]]  
 <[[date|%Y-%m-%d %a]]>

That will append a well-formed org-mode todo to the end of my file. The [[title]] placeholder uses the first line of the Drafts buffer. The [[body]] placeholder uses all the lines after the first. There are positional placeholders, too, e.g. [[line|n]] for the _n_th line of the buffer. So this:

Correct that bad link on the RBAC intro page
Make sure you check the other links, too


* TODO: Correct that bad link on the RBAC intro page
Make sure you check the other links, too
<2014-11-18 Tue>

… in my file, which gets org-mode’s syntax highlighting treatment in the Emacs buffer when I get to it there (along with all the handy text folding, archiving and agenda generation stuff):

Work org

That’s pretty simple, but it solves the thing that’s always vexed me about org-mode in the mobile world, which is how fiddly task capture can be. This reduces it to opening Drafts, typing a line or two of text, then tapping the Send to org-mode inbox action button. That’s as simple as OmniFocus or Things, and Drafts opens more quickly than either of those.

Not Advocatist, but …

I have this idea I’d like to work on some time:

MacRumors has this nifty buyer’s guide that tells you when it’s a good idea to be thinking about an upgrade because a given product family is due. If you take a look at the top, there’s some tidy, consistent markup:

There’s a table (class = buyerstable) and number of data cells with lists (class "buyerslist"), each of which contain list items (with classes of red, green and yellow) wrapping the name of each product family.

So … Nokogiri:

#!/usr/bin/env ruby 

require "rubygems"
require "nokogiri"
require "open-uri"

interesting_products = ["iPad", "iPhone", "iPad Mini", "MacBook Air"]

url = ""

doc = Nokogiri::HTML(open(url))'ul.buyerslist').each do |bl|'').each do |product|
    if interesting_products.include?(product.text)
      puts product.text unless product.text.include?("Gazelle")

So, it seems to me there’s a programmatic way to tell if interesting things might be about to happen in Apple’s product lines. Do I care because I’m interested in knowing the best time to upgrade my Apple products?


I care because most Apple writers become insufferable when there aren’t new products for them to fawn over. They delve into bitter, weird little obsessions, spend their time gloating over nits they have successfully picked, and do weird shit like call out Paul Thurott (whom I have met and is a nice guy who gave me a funny Microsoft mug when I was a Linux columnist) and Rob Enderle (who is an absurd thinker whose main contribution to the world of consulting is the productization of trolling). In other words, Mac writers, given no new stuff to talk about, become as bad as the things they hate, just like Nietzsche says people will.

So it occurs to me that if you’ve got a programmatic way to see if product changes are coming, you’ve got a programmatic way to see if the Mac people have anything worth reading. So if you’ve got an RSS reader that can programmatically turn subscriptions on or off, you’ve got a programmatic way to ignore people who become annoying on reasonably predictable cycles. Alternately, maybe something like grapi would do the trick by talking to Google Reader directly (meaning your changes show up on all your devices).

More Precise Annoyance Removal

But what about feeds that are good most of the time, but have annoyances embedded in them? Kind of a nice NetNewsWire feature is the ability to make any script that returns a valid feed into a subscription. I used the example code from the Ruby 1.9.3 RSS library to make a simple script that reads in a feed, skips the stuff that matches a pattern, and then adds the remainder back to a feed:

#!/usr/bin/env ruby
require 'rubygems'
require 'rss'
require 'open-uri'
require 'sanitize'

url = ''
scrub_pattern = /(the\ week\ in|macalope)/i
title = "Scrubbed MacWorld"
author = "Mike's RSS Scrubber"

scrubbed_items = []
open(url) do |rss|
  feed = RSS::Parser.parse(rss)
  feed.items.each do |item|
    title = item.title
    unless item.title.match(scrub_pattern)
      scrubbed_items << item

rss = RSS::Maker.make("atom") do |maker| = author = = "" = title

  scrubbed_items.each do |scrubbed_item|
    maker.items.new_item do |item| =
        item.title = scrubbed_item.title
        item.description = Sanitize.clean(scrubbed_item.description)
        item.pubDate = scrubbed_item.pubDate

puts rss

This clears out a lot of MacWorld’s “second bite at the apple” (heh) roundup posts, and the Macalope, who is dull.

It occurs to me that maybe the overarching project here is to define a set of feeds I have an uneasy relationship with in a simple YAML file, like:

title: Some Mac Dude's Feed
shortname: some_mac_dude
scrub: /somepattern/

Then genericize the script above so a simple Sinatra service can serve up feeds from an endpoint, like Then they’re scrubbed, available to Google Reader, and I can build the “is this blog going to irritate me when Apple’s not rolling out new product” logic into the app.

Say! We can also add tags!

title: Some Mac Dude's Feed
shortname: some_mac_dude
scrub: /somepattern/
    - mac
    - coffee
    - children

And set up an “annoyance” endpoint on the Sinatra app that can add and destroy annoyances from the feeds served. Then a little mobile app to manually toggle annoyances on and off as they occur to me.

Gosh, Mike …

Yeah, I know, o.k.? I know.

0 to rbenv on Mountain Lion (late 2012 edition)

I thought I was going to sell my 11″ MacBook Air and even had it zeroed out for handoff once I found a buyer, but I decided I missed it, so I set it back up again this weekend, reinstalling Mountain Lion. That meant getting rbenv back onto it with minimal hassle.

If you can live with plain old system Ruby (1.8.7-p358) on Mountain Lion, steps 4 and 7 don’t really matter: Ruby builds with Apple’s own compilers. If you want to have a rbenv-managed Ruby 1.8.7, you’ll need gcc, not llvm.

This is the second time in about a month I’ve been through this, and what I’ve got here represents the fastest path I could manage to get from “new Mac with Mountain Lion installed” to “rbenv that can build rubies prior to 1.9.x.”

  1. If you don’t have XCode installed, you can install the XCode command line tools found here: . Alternately, if you don’t have an Apple account, you can get a package here:

  2. Install Homebrew:

  3. Install a new git from Homebrew:

    $ brew install git

  4. Install Homebrew’s gcc42:

    $ brew tap homebrew/dupes && brew install apple-gcc42

  5. Install rbenv with Homebrew:

    $ brew install rbenv

  6. Install ruby-build:

    $ brew install ruby-build

  7. For ruby 1.8.7, disable Tcl/Tk support to build with rbenv:

    $ CONFIGURE_OPTS="--without-tk" rbenv install 1.8.7-p370

That’s pretty much it. The longest part of the process is downloading and installing the command line tools (115MB), but that’s much better than downloading and installing the behemoth that is XCode, then installing the command line tools.

I suppose there’s one more thing to note, which I discovered in the process of trying to see if there was a quick way to uninstall XCode’s command line tools: There’s no command you can just run to do that, but there’s this helpful script, which I found on Cocoanetics’ website, and which seemed to do the trick:

So, here’s the thing about that Nexus 7

I think I’m probably going to have to own my last post because, you know, we’re not big on memory holes around here. And in my own defense, I meant every word when I wrote it because at the time I was comparing that Nexus 7 to some phantom device I hadn’t really held or tried out or, alternately, my iPad 3. It didn’t seem fair to compare it to the iPad 3, both because the iPad 3 is uncomfortably heavy for my main use cases (reading on the Max, reading in bed) and because the iPad 3s bigness and heaviness comes from the things that make it much, much better than a Nexus 7 for the cases in which I’d used it up to becoming a commuter (as a curiously smooth and low-functioning laptop).

I’d planned to sell the iPad 3 once I was convinced I’d keep the Nexus 7 around. So last week I found myself sitting in a Starbucks up in the Pearl District while a pair of nice but suspicious ladies made me connect to assorted networks and load web pages and generally demonstrate that I was not trying to sell them an iPad case stuffed full of nuts, bolts and wood shavings (which once happened to me while stationed in Korea, except not with an iPad—they didn’t exist yet—but a power amplifier for a radio set, apparently because a Korean depot-level tech decided the guts of an FM radio power amplifier would do him more good than they would my retrans team).

I don’t want to seem like I’m complaining about the ladies. They were nice enough and they were much better to deal with than the people who wrote me for two days straight asking if I wanted to trade my iPad for a hulled kayak, a mostly dry and ungnawed box of Life magazines from 1982, or $50. They were far nicer than the person who wrote me at two in the morning with the simple message “oh you fucking dirty scammer.” And they were less alarming than the elderly gentleman who attached a 1600×1200 picture of his smiling, stubbly face and a message that read:

$$$ how do I call !!! $$$

Eventually the ladies were satisfied, so I initiated a wipe of the device that took an awkwardly long amount of time I filled pointing out the nice features of the case I was throwing in. The transaction concluded and me with some time on my hands, I wandered down to Pioneer Courthouse Square, and then into Pioneer Place, and then into the Pioneer Place Apple Store, where what I really wanted to see was the new iMacs (not there yet) and the newest 11″ MacBook Airs (because I’m a curious soul).

My mood, on entering the store, was a little melancholy. How friendly would the greeters be, I wondered, if they knew what I’d just done? And how would I feel, looking at the new iMac and latest MacBook Air, knowing that the Nexus 7 had shaken my faith in Apple just enough to be thinking the old heresy, that life with a machine I crafted myself, like a dwarvish smith, would perhaps break through the gray sameness of life in my 40s and allow me to stand a bit straighter and meet others with the fell gleam in my eye of a full-on mithril plated nerd? These are the thoughts a technical writer who works in the corner of a pod full of competent, opinionated developers. They aren’t really worthy thoughts. But sometimes, after you’ve just gotten done being scolded for leaving trailing whitespace in a trivial docs commit, or you’ve forgotten that Ubuntu—the training wheels distribution—lets you assign arbitrary ports to sshd with no hassles while CentOS—the training wheels distribution for grownups—has iptables up and running at install, you imagine assorted geek-flavored Charles Atlas outcomes that will allow you to start socking the bullies.

I worked through those feelings in the time it took to mutter “I’m good, just looking” at the greeters, then I brushed past the iPad mini display, not even intending to stop and look because what was the point? I’d forsaken that path. But in that moment, one of the people holding an iPad mini put it down and the person who seemed to be looking at everything but the mini to keep from seeming like they really, really wanted to hold the mini while it was being held by someone else was looking away. So I picked it up.

My main thought was “is the display as bad as everybody claims?” so I opened up Flipboard, which doesn’t have many meaningful or constructive design opinions in its pretty little head but does have nice typography. Before I could consider the display, I noticed how quickly Flipboard opened at all. Just *pop* and there it was. That was nice. I remembered when I finally found a working Nexus 7 at a Fred Meyer and how I actually rebooted it because it was running so slow and I’d just subconsciously made the excuse that it had probably been handled all day and who knew what state it was in. Maybe Flipboard had recently been open already, so that’s not a scientific observation, but it’s not like I was even making some list … I was just curious about the display and noticed. Even when an app is up and the cache is warm, the Nexus 7 doesn’t seem quite as responsive. You get used to it, then you notice when something else isn’t like it.

So I flipped around in Flipboard and thought “this display is not that bad, and it’s very bright.”

I closed Flipboard and opened Safari (also *pop* and then *swoosh* when I loaded Google news), and then I just bounced around, opening things and switching between apps and noticing that the mini was very nimble and smooth and its extra size compared to the Nexus 7 (it’s .6″ wider) didn’t render it impossible to hold (which is something reviewers who have felt hard pressed to notice something have fixated on, saying that only people with giant hands could hope to hold a mini and then noting how tragic that is because their giant hands will then crush the wafer-thin device and leave them weeping and smashing SWAT teams as they blunder down the street wishing they’d bought a Nexus).

At that point, the person who’d been pretending to not stare at the person who had held the mini before me had dropped all pretense of not staring. He wanted to get at that fucking mini. So I put it down and looked at him and sort of raised my eyebrows with a Spockian “hmmm” and walked back out of the store.

By the time I deposited my iPad money and got back to the office, my thoughts had largely taken shape: I was pretty sure I liked the mini better than I did my Nexus 7. It felt faster, all the iPad apps I knew would be on it, and it was lighter and thinner. The display wasn’t as nice, but it wasn’t horrible, either. At the same time, there was probably no getting a mini any time soon. The Apple store website said they were two weeks out. A few weeks earlier, when I’d been researching small tablets, I’d asked an Apple Store lady how they were selling she told me there were lines outside the store each morning. Then she shared a little trick about scoring a mini I’d filed away more as a curiosity of Apple’s ingenious ability to sell a thing it has in stock yet also render than thing unattainable: Going to the Apple Store website at 10 p.m. (no earlier, certainly not much later) would reveal whether minis might not be in stock for pickup the next day. All I had to do was put one in my shopping cart then step all the way through to just before checkout. I asked her why people would queue for something they could just order online the night before and pick up at their leisure. She shrugged and smiled in a knowing way that kept things on this side of respectful, but only barely. Looking back, I have labeled her The Naughty Apple Store Lady.

That trick was on my mind a little on the way back to the office, but I was mostly telling myself that by the time I could just go buy a mini or just put a mini in my shopping cart at the Apple Store site, I’d be over the whole thing and happily entrenched in the Nexus. Heck, I told myself, maybe I’d even build that Linux box and forget all about it!

But that night, in bed with the Nexus, after the last email was read, the last Pocket item checked off, I thought about the trick and wondered if it was true. So I opened up Chrome and browsed to the Apple Store and put a mini in the cart. Then I visited my cart. In the split second before the page loaded, did I see the twinkle in the eye of the Naughty Apple Store Lady? I think I must have, but I couldn’t swear to it now, and either way I was definitely remembering her barely respectful smile as the Apple Store cart page told me I could have a mini held for me for pickup, and that was that. I was down there at lunch the next day.

What can I tell you about the thing? It’s smoother than the Nexus 7 for the things I use it for (page scrolling, especially, is comparatively amazing, but the apps in general are just better put together) and the battery life is great. It’s a much more familiar experience, and after over two years of using an iPad, that counts for something. It handles just fine one-handed on the Max and it’s far more comfortable for the ways I use it than the iPad 3 was. It cost more than the Nexus 7, but I think it was worth it.

Now to endure a few more days of

$$$ how do I call !!! $$$

and offers of slightly rusty but functional bicycles in trade for my Nexus 7.

Open in Emacs Finder Button

Emacs button


So, Dr. Drang wrote (or adapted, anyhow) this handy little “open in BBEdit” button for Finder windows, and I found it intriguing because I wouldn’t mind something similar for Cocoa Emacs at all. On review of what, exactly, the button entailed, I decided I could take Dr. Drang’s work and make a working knockoff (or, as we say in Apple fandom, “samsung it”) over lunch.

After a few minutes with Icon Composer and a few more poking at the AppleScript that drives the button (see where my priorities were?), I had enough to put up on Github, where I bet you can make it better.

Here’s the README:

A very quick, still incomplete adaptation of Dr. Drang’s “Open in BBEdit” button for the Finder toolbar.

This works with the Homebrew’s Cocoa build of Emacs.


  1. Download and drag into your Finder toolbar
  2. Select file(s), click button, see files open in new frames in your Emacs app. If you’d rather they open in new buffers, add this to ~/.emacs:

(setq ns-pop-up-frames nil)

If you haven’t selected any files, it should open the directory represented by the Finder folder you’re in in dired.


  • wait for things to break because this was done very quickly

Use Automator to Append to an org-mode Inbox

I’m pretty sure there are some org-mode modules for skinning something like this cat, but I read a tip in MacWorld today about creating reminders outside of the Reminders app using Automator and it seemed like a thing to adapt to org-mode once I’d finished my sandwich.

So … you fire up Automator and tell it you’re creating a new service, then:

  • you tell it “Service receives no input in any application”

  • you tell it “Ask for Text” and add a useful format reminder, such as “Add an item to the org-mode inbox (item |yyyy-mm-dd)”

  • you tell it “Run Shell Script,” passing input to stdin.

  • you include this script, seasoned to taste where your own org-mode inbox is concerned:

Then you save it as a decent name you don’t mind seeing in your services menu, visit the Services Preferences panel and assign it a shortcut you’ll remember, and you get a quick dialog each time you hit the shortcut key that lets you add something to your org-mode inbox.

It’s super-simple, and you need to remember to separate the todo with a pipe character (and never use a pipe character for the headline of your org-mode entry), then enter your todo date in the correct (yyyy-mm-dd) format. If you don’t add a date, it won’t try to, either.

If you’d rather it use the selected text from your current application, you can always tweak the workflow so the service “receives text” from “any application,” which will prepopulate the popup form with your selection.

For grabbing links or selections out of a small set of Mac apps and getting them into org mode, there’s always org-mac-link-grabber and there’s also the handy org-mac-message for getting links to the current selected message into org-mode. I put that there mainly to save you from doing what I once thought seemed perfectly sensible, which is jettisoning for GNUS.

I guess neater still, were I a “neater still” sort of fellow, would be to grab the selected text of the current application, but offer the dialog, turning the selection into plain text under the new org-mode headline.


 tweetbot  Flipboard











On the left is a screen shot of Tweetbot for iPad browsing one of my Twitter lists. On the right is a screenshot of Flipboard browsing the same Twitter list. 

One of the things I don’t like a lot about Twitter is a convention that’s become common among its more institutional voices, where it’s considered o.k. to repeatedly tweet the same link several times in a day, then again a few more times over a week. I’m not going to argue for or against, but for a time, when I was using Flipboard to browse through my Twitter lists, the practice drove me crazy. I’d see a headline, flip a bit further down the list and see either that headline again or — worse — a slightly different headline. Had I already seen it? Had I already read it? Was it offering some new information on a similarly titled piece? No telling. 

I recently started using Tweetbot to follow my Twitter lists, and noticed the same thing going but felt  more relaxed when it happened. Probably because with Tweetbot it’s possible to rip down a list, nine or ten posts at a time, and there’s no deceptive visual cueing going on, which is something I was irked about  two years ago:

Stuff that looks designed to optimally present information but is actually designed merely to ape the designed presentation of information doesn’t make the information on display any more useful or comprehensible. In Flipboard’s case, it makes it worse, because the design of the app strives to present a sense of competently arranged information but is actually presenting merely prettily arranged information. A tweet that warrants a giant piece of stock art and a large headline on one page suddenly becomes the smallest, least obviously placed aside a few pages later. 

A decent RSS reader (and not Flipboard’s low-density interpretation of Google Reader) would be preferable to both Tweetbot and Flipboard, but Twitter has provided a pressure valve for the need to share asides and no-comment linking that linked lists used to provide, and Twitter is commonly a repeater for RSS feeds, so for any topic you’re trying to follow in depth, Tweetbot’s terse and unromanticized display of The Latest is the most comprehensive and efficient way to get it all in one place. 

Back to BBEdit with a Unix Accent

I have not been enjoying technology much lately, maybe because I’ve been enjoying it too much. It’s been one of those restless periods, but I think I’m coming out the other side.

In the past several months I’ve rediscovered Rails and Sinatra and added HAML & Bootstrap to my repertoire. Bootstrap gives me a lot of what I was getting with Blueprint, and some its markup is close to identical, so it’s been very simple to convert some smaller projects and quickly whip up pleasant front-ends for new ones. Combined with HAML, writing templates for Rails and Sinatra is a dream.

Two things I found that make writing HAML a little nicer:

Serve, a little rack app that “provides the equivalent of the Views part of the Rails MVC,” and can spit out a static version of your work if you just need a static site.

One small project I’m doing with Serve is a simple tech group status board. I can keep a set of maintenance and support events in a simple YAML file and read them in via Serve’s view helpers. I can keep the YAML file in my dock, update it as needed, and let a little Rake job handle pushing a static version of the status board out every so often.

LiveReload, which will watch a local filesystem and tell your browser to refresh when it detects changes.

This is going to sound incredibly lazy, but standing up a quick little Serve site, opening it in your browser, moving the browser over to a second monitor then watching changes to templates and content appear in the browser as they’re made (instead of needing to flip over to reload constantly) just feels liberating, especially if you’re still learning your way through the way some code works. It’s just “change, save, glance / change, save, glance / change, save, glance.”

But there’s also been discontent.

For starters, TextMate and I no longer see eye to eye. When I first started using it I was a Ruby novice and it did some things that made my life much easier. Its auto-indent helped me understand my own code better, I could run a Ruby script with a quick cmd-R, its bundles and snippets were much easier than Emacs and a bit easier than BBEdit. But it has never been a perfect match.

Between BBEdit, Emacs and TextMate, TextMate is by far the least robust. Large files bring it to a crawl and eventually crash it, which has always meant that I’ve had BBEdit laying around to step in when I’ve needed to work through a large file.

From a front-end Web developer’s point of view, I find BBEdit friendlier. The Markup menu is a nicer toolkit than what come with TextMate or Emacs out of the box, and the text filter palette makes more sense even if TextMate’s bundles are a little more keyboard-centric (which I prefer).

From a Rails developer’s point of view, TextMate is still more comfortable, but I’ve developed habits over the past several years that serve me in place of the Ruby-friendlier automation TextMate provides. The thing is, I’m not really a “Rails developer.” I periodically dive into Rails or Sinatra when I need to take a process I’ve automated for myself and hand it off to people who can put text into a web form but can’t run a shell script or learn to configure a text editor to run one for them.  Given nothing to do but Rails work, I’d be thrilled because Ruby’s my favorite language and Rails is very comfortable for me. But nine months into my new job, I’ve hit a few limits in terms of what I can automate for others and I need more efficiency (and HTML-centricity) for the things I can’t reliably hand off to people who aren’t as fluent in HTML as I am. BBEdit’s great when you need to automate text processing for yourself, not build tools to do it for other people.

All of which ignores Emacs. Whenever things start screwing up for me — TextMate crashes more times in a week than a developer’s tool should, for instance — I start eyeing Emacs again.

Emacs has been pretty good to me over the years. One could argue that I got a book contract because I knew how to make light of Emacs in a way that proved accessible both to people who knew what Emacs was to begin with and those who didn’t. It’s a sort of technological comfort food for me: Things go wrong and I go play with Emacs for a little while, tending to my .emacs file and making lists in org mode until I feel better.

So in the past few weeks, TextMate seeming to be twitchier than normal, I went back to Emacs for a bit, first with Aquamacs, then with plain old Emacs via Homebrew, which spits out a very nice Cocoa Emacs. But I’ve never really found Emacs comfortable for HTML editing, and that’s what I’ve needed more of. And I didn’t want elisp in between me and routine automation, much of which I’d be porting over from TextMate. I can get Emacs polished up for use pretty quickly, but it just didn’t feel very smooth and it wasn’t what I needed. I briefly cast about for a copy of an elisp manual at one point, until I remembered I had given it away during a moment where I realized it was just an aspirational bit of clutter I needed to be rid of. I don’t really want to be an elisp wizard, and I haven’t for a few years.

So I got to thinking about my rationalizations for returning to Emacs every so often, and they’re all good enough: It’s portable, so even if the Great Mac Meteor comes and renders OS X inoperable, even on ratty Hackintoshes, I’d have a familiar coding environment. It’s free, so there’re no upgrade fees for new releases. It’s robust. org-mode.

At the same time, things and people change. I’ve been using Macs pretty consistently for about ten years now. Even with Emacs keybindings wired into Cocoa I’m still more likely to use the standard set of Mac keyboard shortcuts these days. I prefer opening up a preferences pane to scanning a file full of configuration variables (and Emacs’ config buffer doesn’t count as a “preferences pane” even if it has been wired up to cmd-,). When I stick a Linux desktop on a VM and try it out in fullscreen mode for an hour, it no longer feels anything like home. It just feels like the product of people who are coming to grips with the fact that “be better than Windows” was a ridiculous goal, and who’re now trying to be better than a Mac (which is also ridiculous — just make something awesome unto itself).

So I fired up BBEdit for a day and it was a joy. Everything about it feels solid. It’s very configurable, so it’s easy to cut down on the proliferation of menu items and features. It respects the Unix heritage of OS X without being a slave to it. Most of the text filtering convenience scripts I’ve written in TextMate, for instance, could just be dropped into the support folder and bound to a key and used right away, because I wrote them as someone whose homeland is a Unix shell environment. Start with STDIN and go from there. So I ponied up to upgrade from version 9 to version 10.

But what about portability and all that? Good questions, never completely resolved when you’re using a tool that’s only available on one platform. At the same time, that one platform is my home and I plan to stay on it for a while. Sitting around worrying about the day it’s not going to be my home anymore isn’t any more productive than taking a course on current divorce law each year: If the giant Mac-eating star goat comes, I will be very sad for a little while, but I’ll just go back to Emacs and stay there. In the mean time, when I need to edit a remote file, I’ve probably got the server it’s on bookmarked in BBEdit.


Put the current Chrome URL in your Safari reading list

… or “Hey, dawg, we heard you like Safari so we put your Chrome in your Safari so you can Safari when you’re done Chroming!”


I tend to do desktop surfing with Google Chrome because I do a lot of “open 10 tabs at the same time” stuff on our Drupal multi-site and Safari’s not very good at that. Sometimes, when it’s time to head downstairs for lunch or by the fireplace for some iPad surfing, I find myself wanting to take a few things I had open in Chrome with me on the iPad. I used to use Pinboard, but Safari’s new reading list is more convenient and doesn’t clutter up Pinboard with short-lived links, so it’s cool that there’s an AppleScript command to add things to it:

And here’s one that does the same thing with the selected NetNewsWire headline:

Hook them up to the actual apps to taste.

I made the mistake of writing a quick Automator workflow that created a Service Menu item to do the same thing with any selected URL in any app, but when I went to try out my new service I noticed Apple had already thought of that. Easier to go into System Preferences and create a shortcut for it.

If you don’t mind the extra keystrokes, you could also just ⌘l then ⌘c to get Chrome’s current URL and use the service, no need for AppleScript at all, but I wrote it all before I realized Apple had done it for me.

What about Firefox?

No real scripting support because Firefox is lame like that and always has been. You can get the current Firefox URL by using AppleScript to press ⌘l then ⌘c:


That MacBook Air (and the iCore of the Future)

I’m officially a fan. I think it’s the  SSD that manages to make an ultralight laptop packing a 1.4GHz processor and 2GB of RAM feel as nimble as a desktop with a 2.4GHz processor and 8GB of RAM. There are some things I don’t do on the Air: It’s not running MySQL, Apache or Rails. But for all the “normal computer” stuff —surfing, writing, mail, RSS, light coding — it’s great. It even seems to run WinXP in VMWare pretty well, though doing that manages to get the (very quiet) fans to spin up.

Some day, if my situation changes such that I don’t want to have a big desktop machine handy, I can see entertaining the notion of owning another “full-sized” laptop, like a MacBook or MacBook Pro. For now, though, I don’t think I’ll ever want to own a notebook larger than an Air. It does everything I need in a notebook at about half the weight and without any sense that I’m making some big tradeoff. In fact, the old white MacBook just feels bloated and unnecessary: A device packing too much because there was a good chance it was going to be The Main Computer for a lot of its anticipated market.

Having had both side by side for a week now, I’ll be the first to say that having both an Air and an iPad is an unimaginable extravagance. There may be times when I’ll be glad to shave an extra pound off my bag and take just the iPad along, but I think I’d also be about as happy having my iPhone in a lot of those cases. During the day, when I’m still working but taking a break from the desk, there’s no way the iPad makes more sense than the Air.

Could it ever? Maybe, but it would involve Apple building the sort of hybrid device that third parties have stepped in and created with iPad keyboard cases, and it would involve Apple opening iOS more than it seems willing to. My day-to-day basics are heavily tied up in things like being able to use clipboard history applets, quick flipping between apps that are guaranteed to remember their states under normal load, and browsers that don’t need to reload tabs if I’ve been away from them. With those things, I could make some of the compromises needed to work around other deficiencies.

I’d like “some sort of hybrid device” a lot, but here’s my notion:

In under ten years, Apple’s going to be selling us iPhone-like devices we’ll jokingly call “iCores,” because they’ll (either literally or virtually) snap into the back of three form factors: larger tablets, notebooks and consumer desktops. The iCore will pack enough RAM, processing power and storage to do everything you need in a desktop computer today (with some help from the cloud). It’ll just be less wasteful about it, because you won’t need three different CPUs, GPUs, storage devices or sets of RAM. Instead, each form-factor will have a slot for some kind of physical interconnect or enough wireless hardware to communicate with nearby iCores and drive audio/video/input: They’ll be thin hosts to a fat client where fat has been defined down to “thin metal wedge you can slide into your pocket and use as a phone, too.”

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.