It seems they have recently removed that experiment, as they sometimes do. I don’t know exactly when that happened, but The Wayback Machine puts it at somewhere between April 21 and now. But despite Google’s removing the experiment, the keyboard shortcuts had still been working just fine for me—until, that is, I revisited the page linked to in the first paragraph. Even just visiting that page, without taking any action, removed the shortcuts. The Accessible View experiment also provides similar keyboard shortcuts, but it does other things I don’t like, such as highlighting the currently selected search result blue.

I took a peek into the JavaScript on that page, and though it was optimized and obfuscated, it wasn’t enormously complicated. It was doing stuff with the PREF cookie, but the cookie’s content was highly opaque. There was a handy _toggle() function which took the name of a feature to toggle. The two currently available experiments, Instant on Images and Accessible View, which pass in the names 'ImagesInstant::PublicOptIn' and 'Axs' to _toggle(). Archive.org tells me that the keyboard shotcurts experiment used the name 'BetaShortcuts'.

So, the obvious next step was to see if running _toggle('BetaShortcuts') on that page would fix up my cookie to give me back my keyboard shortcuts. I fired up the web console from Firefox’s Web Developer add-on and ran that command:

> _toggle('BetaShortcuts')
TypeError: h("e_" + b) is null

D’oh. It’s trying to do something with the page’s DOM—ordinarily, when you click the “Join this experiment” button, it changes the button text to “Leave this experiment”, but there’s no button for the BetaShortcuts experiment to change the text for. The h() function is just a thin wrapper around document.getElementById(). Well, let’s try hacking around this by renaming one of the other buttons:

> h("e_Axs").id="e_BetaShortcuts"
"e_BetaShortcuts"
> _toggle('BetaShortcuts')
undefined
GET http://www.google.com/url?(various opaque parameters) [HTTP/1.1 204 No Content 88ms]

Close the page, and voila! Keyboard shortcuts work again.

Fortunately, Perforce provides a binary compiled against Cygwin. You can download that, drop it in your $PATH, and be on your merry way.

But I happen to like P4Win as a graphical client, and P4Win doesn’t play nicely with the Cygwin p4. Why? Client roots. With P4Win (or any other non-Cygwin client, for that matter), your client root is a Windows-style path, e.g. C:\path\to\root. But Cygwin sees things differently. It wants your client root to be something like /cygdrive/c/path/to/root.

So, if you have a client set up with P4Win and try to interact with the command line p4 in Cygwin, you’ll get messages like this:

'awesomecode.cc' is not under client's root 'C:\path\to\root'

You can get around this by using absolute paths, e.g.:

p4 edit $(cygpath -wa awesomecode.cc)

That gets tiresome very fast, though. But you, fearless reader, you are in luck! I have just the solution for you! It turns out that all p4 needs is a little persuasion to change its PWD environment variable. I whipped up a little C program that fixes up its PWD and exec’s the real p4, so it no longer gets confused.

You can download my program here. Enjoy!

But this post isn’t about Visual Studio. Jeff’s post contained an intriguing link to Steve Yegge’s blog, where Steve goes over some of the new features in Emacs 22. And despite my being a long-time emacs user, I was pleasantly surprised to learn that you can use elisp with find-and-replace.

Now at first, this may not seem like a big deal. You can do a lot with a plain vanilla find-and-replace (M-x replace-string and M-x query-replace (also bound to M-%)), and regex find-and-replaces (M-x replace-regexp and M-x query-replace-regexp (also bound to C-M-%)) are damn powerful. But sometimes, when a sed script won’t do, an elisp find-and-replace can save you a lot of pain.

To do an elisp find-and-replace, do a regular replace-regexp, and set the replacement expression to \, (backslash-comma) followed by an elisp expression. You can use backreferences \1 through \9 as string variables, and you can use \# as an integer variable that is the total number of replacements made so far.

Steve has a number of great examples which I’m not going to repeat here, so I encourage you to go over there and eat ‘em up.

I was eager to try them out, and seeing as how Emacs 22 is over two and half years old, I figured my current Emacs install would be up-to-date. Not so – my MacBook was still running Emacs 21.2.1, which came installed when I bought it in 2006. Fortunately, with MacPorts installed (HIGHLY recommended for anyone running OS X), upgrading was almost as easy as running

sudo port install emacs

I did install instead of upgrade because my emacs install was the default one that came installed and I hadn’t migrated it into MacPorts yet. I said it was almost that easy because after it installed and I went to run it, the old Emacs 21 ran instead, even though the MacPorts binaries directory /opt/local/bin precedes /usr/bin in my $PATH. It turns out that bash uses a hash table, of which I was previously unaware, to cache where frequently used commands are located to avoid searching your $PATH frequently. To fix this, just run hash -d emacs to delete its binding for emacs (or hash -r to clear the entire table), and you’re good to go!

Upon googling for command line wireless tools os x, the first hit was exactly what I was looking for. At the moment that site is down, but Google’s cache saves the day.

It turns out that OS X comes with a nifty little tool called airport, but it’s not on the default path and buried deep inside the file system. I added to my path:

% sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport

To print a list of wireless networks currently in range:

% airport -s

To print the current wireless status:

% airport -I

To connect to a specific network SSID:

% airport -A<SSID>