How to unbreak Emacs somewhat

I’m back to using Emacs for editing C and Python code for now. There are various reasons for this, but mainly it comes down to the fact that I need an editor and not an IDE; creating projects just to edit a bit of code is too much overhead, at least in the IDEs I have tried. Now, one major problem Emacs has had forever is that people (including me) have implemented new modules for it that “unbreak” various parts, but the maintainer has been very conservative about changing anything.

For this reason, here’s what I consider the “minimal unbreak Emacs .emacs” file:

;;; Minimal Unbreak Emacs
; Waste of display space if you can't click on it
(if (not window-system) (menu-bar-mode nil))
; Really.
(iswitchb-mode t)
; Assuming you didn't use Emacs from before when the concept of
; selecting a single region of text interactively was not supported.
(transient-mark-mode t)
; This one is actually fixed in Emacs 22;
(setq x-select-enable-clipboard t)
; The default for "uniquifying" buffer names sucks
(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward-angle-brackets)
; Slightly more debatable
(global-set-key (kbd "C-x C-b") 'ibuffer)

(set-scroll-bar-mode 'right)

; Custom keybindings
(global-set-key (kbd "C-c i") 'imenu)

Technically I shouldn’t be giving you a C-c prefixed function, but I don’t know of another good place for it. Anyways, enjoy. Someday Emacs will come out of the box unbroken; it’s happening, just very slowly.


Federico, self-signed certificates disproportionally affect programmers (particularly Free Software programmers) using random homebrew bugzilla instances. For a website with any kind of real user base, the hosting fees and salaries of the programmers/designers/etc. are going to dwarf (by orders of magnitude) the cost of a SSL certificate. Does it suck that you have to pay a fee to avoid a dialog? Sure. But rather than complain, some smart person needs to think of a way to make a distributed system that actually works with non-cryptographic expert people in some way; i.e. doesn’t just ask you “Do you trust this hex number”?

Two links

I won’t do this too often, but two things I saw today that were interesting:

  • An Ars Techncia article on Larrabee, Intel’s new graphics architecture. Kind of scary they say “micro-OS” instead of “firmware”…is my next graphics card going to be running Linux? Regardless, Ars Technica has a well-deserved place in my feed reader.
  • This thread on the Clojure group by a guy who wrote a DSL and compiler targeting Excel spreadsheets, originally in Ruby and now in Clojure. This is one of those things that remind me how different the day to day life of other programmers is from mine.

The life of a function in the Free desktop stack

The Old Way:

  1. Developer in libfoo (a C library) works on solving a problem, decides to create foo_bar() function
  2. Function foo_bar works, and is committed
  3. A period of time later, a new shared library appears in OS update package
  4. You install the package
  5. You try to use function bar from your favorite $LANGUAGE bindings, but it isn’t bound yet
  6. You curse and go searching bugzilla to see what the status is
  7. If upstream is active, some manual review is done to make sure the function is sanely callable from $LANGUAGE
  8. If the function has some special requirements, sometimes metadata is manually added to hackish .defs files
  9. A patch is eventually made and committed
  10. Another period of time later, new bindings appear
  11. You can call

Note that steps 7,8, and 9 have to be repeated for each binding, be that PyGTK, Gtk#, java-gnome, etc. Even worse they all have divergent .defs files.

The New Shiny Future Way:

  1. Developer in libfoo (a C library) works on solving a problem, decides to create foo_bar() function
  2. If it is not sanely bindable, author gets warning from g-ir-scanner, reworks it or adds metadata, commits
  3. A period of time later, a new shared library appears in OS update package
  4. You install the package
  5. You can call, because your $LANGUAGE bindings use GObject-Introspection

The new way, obviously, is going to be significantly better. By actually including all the metadata necessary to interface with the system in the shared library (.so) itself, we eliminate a large lag time before improvements in the lower levels of the stack become usable to bindings. Even more important I think is that by integrating into the build process of the GObject-based C libraries, we can help ensure that authors don’t add new interfaces that are difficult to bind.

Why am I talking about this? Well, I just reached a major milestone in a side project I’ve been working on. Here’s a screenshot:

Instant GObject/WebKit bindings for the JVM

And not just WebKit of course – this is a large step forward for Java bindings for Gtk, Clutter, libnotify, libgypsy, various canvases like hippo canvas and in general the entire “Free desktop stack”.

Of course because it’s Java, it’s also instant bindings for Jython, Rhino, JRuby, Groovy, etc. Just ran this program with Jython trunk:

from org.gnome.gir.dynamic.WebKit import *
from org.gnome.gir.dynamic.Gtk import *
from org.gnome.gir.gobject import *

GtkGlobals.initCheck(None, None)
win = Window(WindowType.TOPLEVEL);
sw = ScrolledWindow(None, None)
wv = WebView()"")
win.setSizeRequest(640, 480)

I just tossed up a web page for the project here. Right now it’s basically blocked on finishing gobject-introspection itself; finishing the .gir to .repo compiler. So I’ll be looking at that. My personal goal was to get bindings for some canvas (probably hippo), and clutter, along with all of Gtk+.

Let’s take a step back though. What I think is interesting about this is that it enables much more seamless multiple layer applications. I blogged about this before. At the bottom, you have unmanaged C (GObject) code. In the middle, you have a managed, statically typed core (Java/.NET). At the top, you have a managed, dynamic language (Groovy,Boo,Python,JavaScript). GObject-introspection dramatically lowers the pain for going between the bottom and middle layers. Using the JVM (or .NET) makes the middle and top layer transition much nicer, especially for a runtime-native language.

Realistically landing and finishing all of this is probably a year out at the earliest still. But it’s fun to hack on!

Edit: By the way, HotSSH version 0.2.5 is out, and this one actually has a README that tells you how to install it! It fixes various bugs, and most interesting it has the favicon work.