All Tabster does is map Tab and Shift-Tab to Command-] and Command-[, which allows you to indent blocks of text using the Tab key and outdent them by using Shift-Tab. Users of other editors that use these key combinations for block indenting will find this makes switching to Coda a lot easier.
The plug-in requires Mac OS 10.5 and is open source under the MIT license. Source code is inside the bundle.
I am pretty excited at the release of the new Coda plug-in SDK and I have been investigating it in preparation for building a Coda integration plugin for MenuMachine 3. As an exercise, I decided to try building a small, useful plug-in. I noticed that several people on the coda-users mailing list were bemoaning the fact that there was no “smart symbol wrapping” functionality in Coda, such as exists in TextMate.
Smart symbol wrapping is a neat feature for coders. The way it works is that you select some text in the editor and then press a particular symbol key, such as a square bracket. This key press is intercepted and the selected text is automatically wrapped in a pair of square brackets. Smart symbol wrapping handles all the various types of paired symbols, such as braces, parentheses and several other types of symbols such as quote marks.
I decided to write a Coda plug-in using the Cocoa API to implement this feature, which turned out to be reasonably straightforward. The resulting plugin, Wrapster, can be downloaded here.
Please note that you must be running Mac OS 10.5 (Leopard) in order to use this plugin.
The plug-in is open source and released under the MIT License. You can find the source in the plug-in’s bundle wrapper by selecting the plug-in in the Finder and choosing “Open Package Contents” from the Finder’s contextual menu.
The plugin uses a simple property list file (WrapOptions.plist, again in the wrapper) to configure the replacement characters so you can add to or modify the replacements that ship with it, which are:
{ } [ ] ( ) < > " ' “ ” ‘ ’ `
The WrapOptions.plist file contains a comment with instructions for how to edit the file.
You can enable and disable Wrapster in the Plug-Ins menu in Coda.
In terms of implementation, the only slightly tricky thing was finding a way to detect key events before Coda gets hold of them. It turns out that the only way to do this without having access to the internals of Coda is to use an Event Tap, which allows the plugin to capture the raw events posted from the keyboard before Coda’s NSApplication instance gets a chance to process those events. This does mean that in order to use the plug-in, you need to enable “Access for assistive devices” in the Universal Access System Preferences pane, as shown below. If you don’t do this, Wrapster cannot get access to any key events.
The Universal Access Preferences pane
I hope you find this plug-in useful. It certainly has served its purpose for me, I’m pretty familiar now with the Coda SDK and what can be done with it. The guys at Panic have done a great job with the API which is simple and well thought out.
I’d love to hear your feedback about the plug-in (good and bad!).
Update: It seems that Wrapster was preventing Command-] and Command-[ from working. I’ve updated it to version 1.1 and it will now not replace the text if either the Control or Command keys are down, it will just pass the key press through to Coda.
Update 2: Justin on the coda-users mailing list pointed out that Wrapster would activate if text was selected in the page and you entered one of the special characters in the search field. I’ve fixed this now with version 1.2, Wrapster will now only activate when you are actually editing text. Get the update here.
Update 3: Thanks to Rainer Brockerhoff who alerted me in the comments to a more efficient way of handling the Quartz Event Tap that Wrapster uses to capture key events. I’ve updated Wrapster to 1.2.1 and incorporated his suggestions. There is no real need to update to this latest version unless you just absolutely must have shiny new stuff :-).
Panic have just released a new version of Coda, their excellent web development app. The big news for us is that it now includes a very nice plug-in extension API, so we are looking seriously at including full support for Coda in the initial release of MenuMachine 3. It looks like the new API supports everything we need to provide first-class support for MenuMachine, which is great.
Thanks for all your comments regarding other editors, we are certainly looking at all the options that you have suggested. Someone mentioned that it would be nice to have support for GoLive 9. We are not going to be targeting GoLive with the initial release as it simply doesn’t make business sense for us to pour development resources into a discontinued product. I’m not saying we won’t support it (I personally would like to see a GoLive extension, since I’ve spent a lot of time in that environment!) but it won’t be in the initial release.
Firstly, since several of you have asked, I want to give you a general idea of our release schedule. We are aiming for a release towards the end of Q1 2009 and are fairly confident of our ability to hit that target. I know this is probably later than many of you were hoping, but we still have a lot to do. However, we are progressing well and are slightly ahead of schedule. At this stage it’s too early to say when we’ll have a release ready for beta testing.
Back to the main topic. When we were designing the new version of MenuMachine, we wanted to provide users with a choice of multiple menu types. MenuMachine 2 allowed users to select vertically-expanding or cascading menus, but we realize that there are many more menu types that users might like to create, and there are also new menu types that we wanted to implement for the first time.
For this reason, menu types in MenuMachine 3 have been implemented as plugins to the main application. This means that we can easily add new menu types to MenuMachine without having to alter the base application code. We anticipate shipping MenuMachine 3 with a variety of useful menu types and we then expect to release new menu types as we are able to develop them. This means that MenuMachine 3 should become more powerful and useful over time.
We have also implemented our external editor support using a plug-in architecture. This will allow us to easily add support for other editor platforms. We will definitely be supporting Dreamweaver at launch and if we have time the initial release might support some other editors. We anticipate creating editor support modules for BBEdit, TextMate and possibly Coda and Espresso initially, with more to follow. If you have any suggestions for editors that you’d like to see support for, please let me know either via email or in the comments.
