In iCal (10.7.4 and below) there was a Debug menu that among other handy features allowed the enabling of iCal to use the system highlight color for today. The feature still exists in Calendar (10.8 and above), but must be added manually to the preferences.

In order to enable this feature without the Debug menu all you must do is add the CalUIUseSystemHighlightColorForToday key to the ~/Library/Preferences/com.apple.iCal.plist preferences file using any plain text editor (both TextEdit and TextWrangler would work).

First quit Calendar, then edit the plist, and upon relaunching Calendar it should be using the system highlight color selected in the General» Appearance panel in System Preferences.

[crarko adds: I tried this with the 10.8.2 Calendar.app and I believe it worked. I opened the plist in BBEdit and copied and pasted an existing key/value combination, edited the key to match the name above, and set the value to true. I saw some highlighting respect this, although I can't say I'm completely sure what all the intended effects are. Perhaps the submitter will see this and clarify what to look for.]

While better than Lion's behavior, the lack of a true "Save As..." in Mountain Lion frustrates me. I never really saw anything wrong with the old style Autosave feature, where a temporary file gets saved periodically until you close the original file. I liked being able to edit a document and then retroactively apply all changes since the last save to a new file with a different name and location from the old file.

This is what's wrong with the "Duplicate" command, which, when it duplicates the file, includes all the changes since the last save. This forces the user to be prescient about what sorts of changes they may want to make to the file at some point in the future, whereas the old "Save As..." helpfully allows you to move all your recent changes to a different file. Unfortunately for most Apple applications, you are stuck with the new behavior. However, for TextEdit, there appears to be a way to revert to the software's Autosave and "Save As... " to that used by computers since the dawn of time.

In this hint I described how to turn off the auto-save feature for an application, which at least in TextEdit causes the true "Save As..." menu item to re-appear in the File menu and enables the Command-Shift-S shortcut to act as the real "Save As...," not "Duplicate."

When doing this however, there was one problem: the new sandboxing "feature" of OS X does not allow the old auto-save feature of TextEdit to make changes to the document's working directory, so you get annoying pop-up error messages every time TextEdit tries to make the Autosave file. Here how you can fix that.

WARNING: We will be replacing the developer's code signature for TextEdit in this hint. If you have qualms about disabling security features on your computer, stop reading here.

First, open a Terminal window and make a back-up of the application, in case we break something:

cd /Applications

ditto TextEdit.app TextEdit.backup.app

Now, we're going to use codesign to force (-f) the application to use a alternate signing identity (-s). The one we'll use is the dash (-) sign identity. This means the code will use an ad-hoc signing identity, which supposedly means that significant restrictions apply (see the man page for codesign ), but it does seem to allow TextEdit to write to a user's directory so it seems like in this case it's significantly unrestricting the app's permissions. Note that when you do this next step, it will reset the preferences for TextEdit. Also note the second dash after the dash-s, "-s-":

sudo codesign -f -s- TextEdit.app

The normal way to disable the new auto-save is the following:

defaults write com.apple.TextEdit ApplePersistence -bool no

But I couldn't get that to work. The only thing I could think of to do was get rid of the lockfile (not sure this part is needed?) and then copy TextEdit's .plist file to a directory where I could write to it, and then copy it back. Note that in this next part, I am putting a copy of the .plist lockfile and the .plist itself into root's home directory (/var/root) before doing things to them:

sudo mv /Library/Preferences/com.apple.TextEdit.plist.lockfile /var/root

sudo cp /Library/Preferences/com.apple.TextEdit.plist /var/root

sudo cp /Library/Preferences/com.apple.TextEdit.plist ~

cd ~

sudo open com.apple.TextEdit.plist

Change ApplePersistence from YES to NO. Save, and go back to the Terminal Window.

sudo mv com.apple.TextEdit.plist /Library/Preferences/

That's it! Now go enjoy your favorite text editor behaving the way it should be. This trick won't work for any other applications (e.g., Keynote); the "Save As..." menu item doesn't reappear when you disable the ApplePersistence.

[kirkmc adds: I haven't tested this. The warning at the beginning should be sufficient for anyone squeamish about trying something like this.]

If you ever want to create a reminder with an alert time, it's easy to do, and it's similar to Calendar's Quick Entry feature.

Just type something like "Dinner with grandpa at 6pm", and you will get a reminder with an alert at 6pm today. You can even specify a date, or use relative dates like today, tomorrow, etc.

[kirkmc adds: This makes sense, and it's good to remind people of it.]

Inspired by an Jinx's article about building your own fusion drive I've decided to take it one step further and brew my own with full OS X installation on it.

First, I needed to put two drives in my Mac. I already had a Crucial M4 SSD and 500GB HD so I a bought hard drive caddy and put my 500GB Momentus XT in it.

That was the easy part. Now how to make them work? In Jinx's article you can read that GUI Disk Utility does not offer needed functionality. It's available only in command line version, diskutil. But from my previous installation I remembered that there is access to terminal in OS X's recovery mode.

It was downhill from there. Create a logical volume group, get the UUID and create the volume. The OS X Installer recognized the volume and installed nicely. After the whole process was over, I did tests similar to those that Jinx mentioned and the drive does, indeed, behave like a fusion drive - files used more often end up on the SSD and less used are shuffled to the HDD.

You can see screenshots and more information here: Mountain Lion on home made Fusion drive

[kirkmc adds: I don't usually run hints that don't explain things, but the first article linked above goes into great detail. I'm tempted to try this out, as my Mac mini has both an SSD and a 750 GB HD, but I'd need to move all the files - my music collection - from the HD to an external drive. I might try and get to it this week.]

If you have Twitter handles for your friends and colleagues in your Contacts, you can easily view tweets those people have made. Just open a card in Contacts, click on Twitter, then choose View Tweets. If you have the official Twitter app installed, it will open displaying tweets from that person. If not, a web page will open on the Twitter web site.

You can also tweet to someone from OS X by clicking on Twitter, and choosing Tweet, as long as you have set up your Twitter account in the Mail, Contacts & Calendars pane of System Preferences.

While viewing tweets is nice, it would be even better if they could open in one's favorite Twitter client. But that would presumably involve hacking Contacts. Anyone interested in trying to figure it out?

I'm not sure when this became available, but I don't seem to remember it happening before 10.8. You can now take screenshots of sheets within a window by pressing Command-Shift-4.

A sheet is a dialog that drops down from a window, but is attached to that window. To take a screen shot of one, press Command-Shift-4, then press the space bar, which displays a small camera cursor that you use to select the window to shoot. If you want to take a screenshot of a sheet, press the Command key, and you can select only that sheet, and not the entire window behind it.

You can try this by going to the Finder and pressing Command-Shift-G, or choosing Go > Go to Folder; what displays is a sheet.

[kirkmc adds: I certainly didn't know this, and don't find it anywhere on the site.]

If you installed the Java for OS X 2012-06 update, you'll have found that it does the following:

"This update uninstalls the Apple-provided Java applet plug-in from all web browsers. To use applets on a web page, click on the region labeled "Missing plug-in" to go download the latest version of the Java applet plug-in from Oracle."

If you wish to re-enable the original Java applet plug-in - which is not uninstalled, as claimed above, but simply disabled - Apple has published a technical note explaining how to do this. There are a few Terminal commands, including creating a couple of symlinks. The technical note also explains how to disable Java Web Start.

The technical note also gives a URL where you can download the Oracle Java 7 JRE, which will be the future version of Java for OS X.

You can change the default calendar event sound and all day event time. These settings are stored as part of each individual calendar.

Locate and open in TextEdit:
~/Library/Calendars/UUID.calendar/LocalDefaultAlarms/EventAllDayAlarms.icsalarm ~/Library/Calendars/UUID.calendar/LocalDefaultAlarms/EventTimedAlarms.icsalarm

The default all day event time can be changed to 6 am, for example, instead of 9 am:
TRIGGER:PT6H

You can change the default event time to values not available in the preferences. This can be a positive or negative value, for instance 3 hours before:
TRIGGER:-PT3H

The alert sound can be specified (without a file extension) using anything in your user or system sound folder:
ATTACH;VALUE=URI:Basso

Apple recently published a technical note about a problem saving photos from Mail to iPhoto in Mountain Lion. I actually came across this problem recently, and there was no feedback suggesting that the photos were not saved. Fortunately, I had a Time Machine backup of the email containing photos in question.

The fix is simply this: launch iPhoto, then drag the photos - one by one - from the e-mail onto the iPhoto icon in the Dock.

Recently I became so sick of the slowness of my MacBook Pro (late 2011 model), which has a 2.4 GHz Intel Core i5 with 16 GB RAM running Mountain Lion 10.8.2, that I decided to buy a 120 GB Kingston SVP 200 SSD drive for my boot drive and put my previous 500 GB Hitachi HD in place of the DVD drive.

I left my old system in place on the old drive and did a clean install of Mountain Lion 10.8.2 on the SSD. I then set up my main user account with the same name and password as before. In the Users & Groups preference pane, I right-clicked on my account name and selected Advanced Options, and set the location of my user account to be my old user account on the secondary drive now named Data HD. Obviously, for all permissions to work correctly you need to keep the new user names and passwords the same as the old ones. That all worked fine, and when I rebooted and logged in to my account, all my Users are on the Data HD. I then used Migration Assistant to pull over all my Apps to the SSD boot drive.

Encryption of Data HD

Control-click on a disk in the Finder to encrypt to encrypt it (in a Finder window, the Finder sidebar, or on the Desktop). Choose Encrypt "disk name" and enter a password. You’ll have to enter the password a second time, and you won’t be able to go any further unless you also enter a password hint. I tried this method and it didn’t appear to work properly so I used the Terminal approach.

Prepare a disk by converting

You encrypt disks with the diskutil command, but first, you have to convert them to a format called CoreStorage. Start by running the diskutil list command, which returns a list of all your disks, like this:

The disk I want to encrypt is Data HD and to the right of the name you can see the identifier which is disk1s2. With that information I could convert that disk the CoreStorage format with the following command:

sudo diskutil corestorage convert disk4s1

Terminal will request your administrator’s password, then will begin the conversion process. Encrypt the disk

The important information above is the LV UUID, or logical volume universally unique identifier. Using that information, you can then run the command to encrypt the disk, as follows: Replace password with your password. The next step will ensure that the Data HD gets mounted during the boot process so that your accounts are available. For this you need the excellent program Unlock by Justin Ridgewell. Full instructions for installation are on his page.

His script runs as follows: Following conversations with Justin, it is probably worth checking that you have an entry for Unlock: Data HD in the System Keychain. Also the script will be installed at /Library/LaunchDaemons/name.ridgewell.unlock. He also advised setting up another Admin account on the SSD in case one ever needed to do an decrypt the Data HD in case anything goes wrong. The command for that, using the example of my Data HD above, is: Obviously a bit of clean-up is necessary. For instance, all the Application icons in the Dock will be referencing the Applications on the original hard drive, so you need to delete each one and replace them by dragging the Applications to the Dock that were moved to the new SSD. Finally, I used Carbon Copy Cloner to copy the user folder from Data HD to another drive, re-formatted the Data HD to remove all the Applications and System files, and then cloned the User folder back to the Data HD. Then I tested all my Applications to make sure everything was working. So far so good and the performance increase is well worth the effort. Boot time is down to 10 seconds and all Applications open instantly!

[kirkmc adds: I wrote a Macworld article about disk encryption a couple of months ago. This hint uses that process, but goes a bit further.]