Hi Magitfolk, I was working on converting Magithub over to the new extension framework, and I started wondering: what exactly does it buy us? Us as extension writers and users of Magit, I mean. As happy as I am that Magit is considering extensions to be first-class citizens, I don't see how the current architecture actually provides much benefit.
Let's look at how the architecture works. The primary interface is the magit-extension struct, which is passed to magit-install-extension. This struct has entries for a keymap, menu entries, magit actions and commands, and a remote-string hook. These are all installed when the magit-extension struct is passed to magit-install-extension; for the two example extensions, this is done when the file is required. The whole API feels very "un-emacsey" to me. That's not a very clear thing to say, so let me explain. In Emacs, APIs, especially those for extending existing code, typically follow a few principles. They use existing infrastructure if possible; they don't add extra layers of indirection or abstraction; they're easy to use dynamically from within the editor; they allow extensions to be written in the same way that the core was written. I feel like this API falls down on all these counts. It adds its own way of adding keybindings and hooks, it only works at initial load time and so not for interactive development, and the extension API is clearly second-class relative to the code used in the core. Not wanting to just complain and not contribute anything, I drafted a comparison between the existing API and the sort of API I'd like to see: http://gist.github.com/504064, along with comments about why I think it's better. I'd be happy to implement this if people like it. Anyway, I wanted to raise my concerns. For the time being, I'll be developing Magithub without using this API, but I have high hopes for its improvement. - Nathan Weizenbaum
