OS X Mountain Lion: Need to reinstall Xcode command line tools

So I upgraded to OS X Mountain Lion yesterday. The install was pretty smooth (though had a tough time with the redeem code for the upgrade, worked on the third code that Apple sent across).

Most of the software is working fine. However, I found that my existing Xcode installation needed an upgrade (via a Xcode install from the App Store).

The problem is that any new Xcode install seems to nuke the command line development tools (think make, autoconf, etc.). The solution is pretty simple though. Once Xcode has been installed, run Xcode and then open the preferences. There is a section on downloads, which lists installing the command line tools as an option.

Voila! Issue resolved.

The Missing iSync in OS X Lion (and what to do about it)

The short answer to someone looking for a solution: just copy over iSync from your Snow Leopard installation back to the /Applications folder in Lion, and also copy the phone plugin you need back into /Library/PhonePlugins folder. Everything will be as it was. Enjoy.

The longer story requires more explanation …

The Problem

I have been looking forward to upgrading to the latest version of OSX (Lion) ever since the announcements were made in the WWDC earlier this year.

However, in the middle of the whole slew of new functions and features (“250+”), Lion is also leaving behind a few things – notably Rosetta (the PowerPC translation layer) – and the iSync and FrontRow applications.

The demise of PowerPC emulation has been long in coming, and was not really a surprise, given that it has been 6 years since Intel became the official CPU for Apple machines. The main impact really seems to be for Quicken users, which might actually be a blessing in disguise, given how pathetic Quicken really was on the Mac.

iSync has been removed presumably because it has been one of the “low usage” applications on the platform. iTunes is the center of most of the Mac based synchronization these days, along with MobileMe for the cloud side of things.

However, iSync has been a key feature of the OS for me, as I carry a non-iOS phone (a Nokia E71 actually), and being able to seamlessly synchronize my contacts and calendars with the phone using iSync made it a key part of my workflow (I even have some Automator scripts to make this easier). And iSync has been able to synchronize over Bluetooth, unlike the tethered experience with the iOS devices so far (though OTA sync is on the way with iOS 5 later this fall).

Alas, OS X Lion removes the iSync application from the hard disk once it is installed, and for a time I thought that this was end of the line for the convenience I had with the E71, and would need to go back to the darks days of manual data entry for the addresses (manual entry of calendar entries is too much of a hassle on the phone, and would need to be dropped all together).

The Solution

Before installation of Lion, I had taken a full disk image of my previous Snow Leopard installation using the excellent SuperDuper! Disk cloner.

This was more from a backup and recovery perspective, but allowed me an unexpected solution to the iSync quandary – on a whim, I attached the Snow Leopard disk to the Mac running Lion, and clicked on the iSync application. Voila! iSync works exactly as it should!

In hindsight, this is not really surprising, since iSync really has been a front end for the underlying sync services (which are still around in Lion), and for managing phone and device specific plugins.

All that was needed was to just copy over iSync back into the “/Applications” folder, and also copy the phone plugins (just one in my case) to the “/Library/PhonePlugins” folder.

In summary, while Apple in its immense wisdom took out a feature that was useful to some (albeit a minority), getting it to work again was surprisingly easy. Will need to check out the situation with FrontRow next time.

[Update on July 22, 2011]

Looks like a similar recovery process exists for FrontRow as well. See this article at Macworld.

Three nifty alternatives to the M-TAB key in Emacs, and a replacement.

The M-<TAB> key in Emacs provides a useful completion function (`completion-at-point’), which tries to complete the current symbol at point to something useful, usually based on other symbols in the buffer which have the current partial symbol as a prefix.

However, using this key is a pain in most OS GUI systems, since it is usually mapped to the Task Switching function as well. Note that the <Alt> key doubles as <Meta> on most keyboards.

Emacs provides two documented alternatives, <Esc>-<TAB> – which requires a trip away from the home rows to the <Esc> key, and “C-M-i”, which is far easier to type.

In fact, there is a third way of inputting an equivalent key sequence: “C-[ C-i”, which is “<Control>-[“ followed by “<Control>-i”.

This works because “<Control>-[“ (that is the left square bracket) is equivalent to the <Esc> key, and also works as a <Meta> key.

The Alternative to <Meta>

In fact, “C-[“ can be used anywhere a <Meta> is required. E.g.,

“M-x” can be replaced with “C-[ x”

<Esc> <Esc> <Esc> (to invoke `keyboard-command-quit’) can be replaced with “C-[ C-[ C-[“.

Using “C-[“ instead of <Esc> or <Meta> has the advantage that the key sequences can be invoked from the home screen, reduces hand movement (at least on a QWERTY keyboard), and also helps avoid the finger contortions that are otherwise often needed to access the <Meta> key.

Note that sequences which involve both <Meta> and <Control> keys can also be invoked, as long as the “C-[“ is entered first. E.g.,

“C-M-x” (to invoke `eval-defun’ in an Emacs lisp buffer) can be replaced with “C-[ C-x”. Sweet.

Firefox 3.6 finally allows true Fullscreen mode on Mac OSX

Updated to Firefox 3.6 today. As usual, a very solid update, and was pleasantly surprised by the full-screen mode (finally!) that works exactly as you would want it. This was one of the few areas where Firefox on OSX was lagging behind as compared to other platforms.

There were a few plugins that claimed to enable this in prior versions, but never worked very well.

The option is available under the “View”menu and has a standard Apple-Shift-F shortcut as well.

Emacs function to add new path elements to the $PATH environment variable

A very simple eLisp function to add new path elements to the PATH environment variable. Very useful for adding new comint executables from within .emacs/init.el files.

(defun my-add-path (path-element)
 "Add the specified path element to the Emacs PATH"
  (interactive "DEnter directory to be added to path: ")
  (if (file-directory-p path-element)
    (setenv "PATH"
       (concat (expand-file-name path-element)
               path-separator (getenv "PATH")))))

gnuplot with AquaTerm on OSX Snow Leopard

The gnuplot graphing utility has always had excellent support for multiple terminal types. While the X11 terminal is a satisfactory GUI view for the graphs, I prefer to use the AquaTerm terminal on OSX as it is more ‘Mac-like’ and feels more natural.

Also, I do prefer to compile gnuplot by myself on OSX rather than downloading the pre-packaged binaries – as this gives me more control over the compilation (including getting around the stupid Apple readline bug – where Apple has essentially shipped a broken readline by using libedit to emulate the non-existent libreadline).

This local compile requires that AquaTerm be installed so that the library dependencies for aquaterm exists in:

and the corresponding headers are available at:

In addition, the AquaTerm.app itself resides in /Applications.

However, on OS X Snow Leopard, there is a catch – the version of AquaTerm is 32 bit, whereas the default compilation of gnuport results in a 64-bit version – which is not able to load the 32-bit libaquaterm dynamic libraries.

In such a case, the gnuplot compilation does succeed – however, the default terminal becomes the X11 version – which is back to square-one.

A darwinports port does exist for gnuplot – however, as mentioned in an earlier post, this port seems to depend on half of the port repository (i.e., a ton of stuff you do NOT want gets installed as well).

However, there is a easier way to get around this situation. Here’s how.

First install the default binary for AquaTerm from SourceForge and install normally. This step is to basically setup the right folders and symlinks so that you do not have to muck with these later
Now install AquaTerm again from Darwinports – this port has the correct patches needed – and more importantly – builds a 64 bit version by default. This will also install the application under /Applications/MacPorts/

Now comes the fun part. We will replace two folders from the darwinports version to the previously installed AquaTerm.
- Step 1: Replace /Library/Frameworks/AquaTerm.framework with /opt/local/Library/Frameworks/AquaTerm.framework. This will ensure that the correct 64 bit AquaTerm libraries get referenced by the gnuplot compilation
- Step 2: Replace /Applications/AquaTerm.app with /Applications/MacPorts/AquaTerm.app. This will ensure that the correct 64-bit AquaTerm binary is in the correct location
- Step 3 (Optional): You can now uninstall the darwinports version by running sudo port uninstall aquaterm from a terminal window
Download the source code for gnuplot and extract the same.
Run ./configure (using a command line parameter to ignore the broken Apple readline) and then make and make install (install will happen in /usr/local)

That’s it! The compilation should now succeed and gnuplot will be linked with the correct 64-bit aquaterm dynamic library. Enjoy!

Use the Capslock as a Control key on OSX for Emacs

This is an absolute must, unless you like contorting your fingers and risk RSI. It is also an easy thing to do on OS X.

You need to bring up the System preferences → Keyboard & Mouse

and then click the “Modifier Keys” to remap the Capslock to Control.

This is available on OS X 10.4 and later versions.