On Wed, Aug 4, 2010 at 6:55 PM, Philip Jackson <[email protected]> wrote: > > Yann - what do you think?
Hi, sorry for the delays it's kind of crazy at the moment :) Basically I'd like to stress the fact that the extensions API is actually *not* an API. It's some kind of POC, covering only the things that were required to be able to split things out of magit "core". So I totally agree that it probably does not cover at all extension writers needs. Now, in my view, it's only a first step towards a cleaner interface, that must be grown according to some real use cases. magit-svn and magit-topic are only providing basic ones. Still I personally see the current situation as a (little) progress, compared to the previous one: it's now actually possible to generate magit-like interface from the outside of magit (which was impossible due to both the absence of hooks and the use of "static" macros). So once again, the only goal of this first step was to break the barrier. Next step is to make it cleanly. In this regard, I'd say that developing an extension outside of the magit repository right now *is* premature ;) Then, and only then we might see an ecosystem of extensions grow. I'm thinking of the non-SVN vcs support, an interface for repo (android) would be great, and some integration with patchwork (used for example by org-mode for patch review) could definitely be used. I totally agree the shape of extensions currently sucks (except for the inserter/actions definition part, which looks just like regular inserter code, so I guess it's mostly right). I think in the near future, they should probably turned into minor-modes. Having a quick look at Nathan's proposal, I think that should include what's in there, solve the activation/deactivation issue (which also totally sucks) and even allow a per-project setting (which I'd like a lot). I have to admit that for my needs, the inserter code was clearly the main target (I need to display different things in magit-status, from extensions). The rest was only required side-effect, so it's definitely not polished. >From what I understand, Nathan's focus is more on the minor-mode aspects. So I see no fundamental incompatibility in all this. Quite the contrary actually, and I'm pretty happy to see that chances are we might end up having something really nice. All we need is code :) Yann.
