Prototyping a Ruby IDE with Macros
In my last blog entry, I mentioned the little macro library I’ve been working on. This comprises a set of code routines to add extra Ruby and Rails editing and project management features to Ruby In Steel. My original idea was to write these routines simply as a convenience to let users create new editing features without having to grapple with the VB macro language and the baroque complexities of the automation model.
In fact, this is rapidly turning into a quick prototyping tool. When we have an idea for some potentially useful feature we can try it out in the form of a macro. If, at a later date, we decide we don’t really like the feature after all, well, it’s no great loss – we haven’t ‘hard wired’ it into the Ruby In Steel code-base so it’s not going to be any effort to remove it. On the other hand, if it turns out to be genuinely useful, we can subsequently rewrite the feature and make it an intrinsic part of the IDE.
Already I can think of a few of our macros that are candidates for ‘built-in features’ at a future date. Being able to navigate between a Rails controller and its view is one such feature. This is already implemented in another IDE, RADRails, and I openly give them credit for the idea. It was, in fact, initially brought to my attention by a user of RADRails who requested the same feature for Ruby In Steel. I recently wrote some macros to implement this. Using my macros, you can put your cursor over a method name (say def show) in a controller file (say, blog_controller.rb) and the macro will load up the matching view (/views/blog/post.rhtml). Run another macro in the view to go back to the controller and position the cursor over the matching method. It’s a pretty simple feature, really, but I can see why people like it.
Macros are a light-weight variety of automation – they skate about over the surface of Visual Studio. At the other extreme are ‘packages’; these are potentially big, complex applications which get right into the inner workings of Visual Studio and are able to construct their own programming worlds inside the Visual Studio solar system. Somewhere in the hinterland between macros and packages lie add-ins (contrary to popular belief, incidentally, Ruby In Steel is most definitely a ‘package’ and not and ‘add-in’). Add-ins are a bit like more tightly-integrated macros and they can, indeed, be created by converting macros.
I guess any macros that don’t quite make the grade into the inner world of the Ruby In Steel package might, at some stage, be bundled together into an add-in. At any rate, for the time being, macros are proving to be remarkably useful as a way of testing and trying things. It’s just a shame they have to be written in VB. Personally, I’d rather write them in Ruby ;-)