Begin main content

More Apple X11.app wierdness

When you are running your own window manager (and with the quartz-wm in proxy mode for the clipboard support), expoze works with X11 windows. Amazing!

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.

07:02 PM, 22 Aug 2004 by Mark Aufflick Permalink | Comments (0)

Sensible Emacs usage with Apple's XCode

The new version of Apple's XCode mercifully allows you to use an external editor, and the integration seems to be quite thorough. Of course for the old time Mac users there is BBEdit integration. I was a big BBEdit fan before I became a Unix-head (which was well before MacOS X).

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.

12:13 PM, 22 Aug 2004 by Mark Aufflick Permalink | Comments (2)

Trackpad scrolling for Mac Laptops [www.ragingmenace.com]

For some time now, high end Wintel laptops (Toshiba ones at least) have had a sexy feature that makes the far right and bottom of your trackpad to function like a scroll wheel. In other words, if you stroke up and down the far right edge of your trackpad, your current window scrolls up and down.

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&#8212;another of my (very few) essential OSX addons.

12:08 AM, 18 Aug 2004 by Mark Aufflick Permalink | Comments (0)

Emacs on MacOS X goodness

First, thanks to XCode 1.5's support for external editors, my desire to start writing some Mac software doesn't mean I have to learn YAE (yet another editor).

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

03:19 AM, 15 Aug 2004 by Mark Aufflick Permalink | Comments (0)

Logged Query Analysis for Postgres [pqa.projects.postgresql.org]

This is absolutely legendary. Very simply, pqa analyses your postgres logfile (after tweaking the logging level a bit in your postgresql.conf) to produce reports on:

  • 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...

03:08 AM, 13 Aug 2004 by Mark Aufflick Permalink | Comments (0)

Web CMS Face-Off [www.eweek.com]

This face-off between opensource perl Bricolage, InterWoven TeamSite and others gives Bricolage a good wrap.

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...

09:23 PM, 11 Aug 2004 by Mark Aufflick Permalink | Comments (0)

This is brilliant! Part 1 of 3, this article looks at the first PPC ship, the 601, and how it was designed to bridge from POWER to PowerPC, then continues to cover the rest of the 60x line.

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 ;)

04:18 AM, 05 Aug 2004 by Mark Aufflick Permalink | Comments (0)

XML

Blog Categories

software (41)
..cocoa (23)
  ..heads up 'tunes (5)
..ruby (6)
..lisp (4)
..perl (4)
..openacs (1)
mac (21)
embedded (2)
..microprocessor (2)
  ..avr (1)
electronics (3)
design (1)
photography (26)
..black and white (6)
..A day in Sydney (18)
..The Daily Shoot (6)
food (2)
Book Review (2)

Notifications

Icon of envelope Request notifications

Syndication Feed

XML

Recent Comments

  1. Mark Aufflick: Re: the go/Inbox go/Sent buttons
  2. Unregistered Visitor: How do make a button to jump to folder
  3. Unregistered Visitor: Note I've updated the gist
  4. Unregistered Visitor: umbrello is now an available port on macPorts
  5. Unregistered Visitor: Updated version on Github
  6. Unregistered Visitor: Modification request.
  7. Unregistered Visitor: Accents and labels with spaces
  8. Unregistered Visitor: Mel Kaye - additional info
  9. Unregistered Visitor: mmh
  10. Mark Aufflick: Thank you