Well, sort of. It throws around all the windows correctly; and when you click one it comes to the top; but it doesn't change X11's window stacking order because front clicks are sent through to the window that used to be on top instead of the one that Quartz has now placed on top.

But hallelujah, XCode supports emacs integration! And, it's quite smart - but yet not quite smart enough :/

It uses my all time favourite gnuserv/gnuclient (with the gnuserv-compat.el library so it can run in GNU emacs), and Apple have put a Darwin compatible gnuserv binary in /usr/bin/gnuserv. This is handy even if you (like me) run fink installed emacsen.

But this is a Mac, so you don't want terminal emacs... Carbon emacs is nice, but I want to use X11 GNU Emacs. Problem is, the way XCode interacts with gnuclient is a bit annoying.

First up, it executes /usr/bin/emacs with no arguments inside a Terminal.app window. You have to configure your .emacs file to start gnuserv-start as per these release notes.

One easy thing you can do, is start gnuserv by hand in your X version (M-x gnuserv-start) and not in your .emacs file. Then, when you double click a file in XCode, it will start a (useless) console emacs, and use gnuclient to open the file in your X11 Emacs.

So far so good - but two emacs processes is heavy, so i replaced /usr/bin/emacs with a hard link to /usr/bin/true ;)

See Update 3 below for the right way to do this!

This only leaves two problems:

• A Terminal.app window is brought to the foreground each time, but we want X11 brought to the foreground instead
• XCode asks gnuclient to open the file in the same frame but I want it in a new frame. Presumably this is because GNU Emacs doesn't support multiple frames (ie. across multiple ptys) in console mode, which is all the Apple supplied emacs supports.

The emacs support seems hard coded - I can't find any scripts that do the work to hack away at. Maybe I can replaec Terminal.app with an AppleScript compiled .app that ignores the calls that XCode is making and thus just leave the gnuclient calls (which appears to be executed by XCode directly - not via Terminal.app), but also to tell X11.app to come to the foreground when (the new) Terminal.app is asked to go to the foreground.

Seems like a lot of work. And I don't do any commercial Mac development, so I probably won't bother!

Annoying though...

UPDATE

It seems the link to /usr/bin/true didn't work - XCode must realise that emacs wasn't started.

What does work though is to move aside /usr/bin/emacs and replace it with a symlink to your X11 version (eg. /sw/bin/emacs-21.2).

Still have both of the bulleted problems abouve though.

Then I had the great idea to move gnuclient to gnuclient-bin, replace gnuclient with dtemacs (hard coding DISPLAY to :0.0). I thought it might fail if XCode exec-ed the binary directly, but it didn't seme to make any difference, so perhaps the gnuclient protocol is coded into XCode??

If an Apple developer on the XCode team reads this - please give us an option to tune the system calls for emacs :)

UPDATE 2

Ok, so this is REALLY bogus, but if the bazillion Terminal windows annoy you, here is what you can do:

1. Symlink your X11 emacs binary to /usr/bin/emacs
2. Have your .emacs (gnuserv-start) as per above
3. Fire up an XCode project, and open a file with emacs as the external editor
4. [Terminal.app will launch your X11 emacs, and subsequently the frame will have the file opened in it by the gnuclient call]
5. Minimise the Terminal.app window, but leave it running.
6. in a shell, rename /Applications/Utilities/Terminal.app to something else.
7. Yes you heard me! Rename the sucker.
8. Now you can double-click in XCode and open the file in your running X11 Emacs process in the front-most frame with being annoyed by Terminal.app windows

Unfortunately you will have to repeat these steps every time. Also, if you symlink X11.app to Terminal.app it will get raised, but none of it's windows will so that kinda defeats the purpose.

If the next version of XCode doesn't help, I'll come up with some Applescript wizardry for a replacement .app and a script menu entry to do all the stupid renaming etc.

UPDATE 3

You can actually tell Xcode which emacs binary to start up using the Expert preferences. Simply run the following in a shell with the path to your custom installed emacs:

defaults write com.apple.Xcode PBXEmacsPath /opt/bin/emacs

Still doesn't address the Terminal problem though.

It's even more addictive than a scroll wheel since your trackpad is right under your hands at all times.

Well, now you can get this on your OSX Mac laptop as well thanks to a very smart Control Panel called SideTrack from Alex Harper (RagingMenace.com<.a>). It's currently in public Beta, but I have yet to see any SideEffects on my original TiBook running Panther.5

This guy also provided some enhancements to uControl—another of my (very few) essential OSX addons.

However, coercign Xcode to talk to a running X11 emacs using gnuserv seems to be tricky, so I'm investigating Aqua emacs. Apparently cvs builds of emacs can now generate a .dmg emacs installer for Aqua. My cvs tree is still downloading so we will see.

Since Applescript is still handy even on OSX, the emacs lisp functions to call applescript from within emacs may be useful (on Steve Wainstead's advogato blog).

Elsewhere on Steve's blog is an excellent lisp func that starts tailing a logfile in a new shell buffer and frame in one easy step (here).

Many more great tips here: http://www.emacswiki.org/cgi-bin/wiki/MacOSTweaks

• The most expensive (slowest) queries
• The most frequently run queries
• The queries that took the most aggregate time

Very simple - but very beneficial when you have to optimise a large amount of code pumping the database as fast as it can.

The biggest deficiency it has is that it doesn't log which database is involved - I'll take a look at the code and the logs to see if that is possible, but it's written in ruby...

Maybe I should port it to perl, but then I'd have to maintain it...

Bricolage rated as many "Good" and "Excellent" rankings as TeamSite and it's "Cons" section was shorter.

So why would anyone shell out $40k USD for TeamSite? It's not like their support is amazing or that its easier to find TeamSite developers than Perl/Mason developers...

If you're into processor design you will love this series. The same author has apparently written a more in depth history of the Pentium line, but I like my processors in RISC thanks ;)