Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Archive for the ‘TextMate’ Category

Everyone Who Tried to Convince Me to use Vim was Wrong

A couple weeks ago, I took the plunge and switched to vim (MacVIM, to be precise). It wasn’t the first time I tried to make the switch, and I had pretty much written it off entirely.

Why? Because the past few times I tried switching to vim, I took the advice of a master vim user, and quickly sunk into the quicksand of trying to learn a new tool. In every prior attempt, I gave vim a few days before I gave up. And every time, I managed to get virtually no work done the entire time, spending about 90 percent of my day fighting with my editor (a more charitable way to put it would be “learning my editor”).

Invariably, the master vim users that were helping me make the switch would encourage me to stick it out. “If you just give it a few weeks, you’ll never want to switch back.”

The trouble was, I had work to do. I could only switch editors if the new editor did not significantly impede on my day-to-day work. I can already hear the responses: “That’s simply impossible. It’s a new editor designed for advanced users. You’ll just have to put up with the pain until you get used to it.”

Here’s the thing, though: I didn’t really have to put up with a huge amount of pain when switching to Textmate for the first time. In fact, it was downright pleasant.

The last few times someone tried to get me to switch to vim, I issued them a simple challenge. Can you tell me a way to switch that will not significantly reduce my productivity for the first few weeks. It wasn’t a challenge that was intended to fully shut down discussion. When I really thought about it, Textmate wasn’t doing all that much for me. It was a glorified Notepad which had working syntax highlighting and understand where to put the cursor when I hit enter (most of the time).

I don’t actually use “snippets” all that often, or all that many “commands”. I don’t mind the extensibility of Textmate, but I’m not a hardcore Textmate hacker myself, meaning that I’m ok with any editor that has the same level of extensibility that Textmate has (namely, all of them).

Despite what I considered a relatively reasonable request, my challenge was met with disdain and even anger by most of the people I talked to. “If you feel that way, Vim probably isn’t for you.” “You’re learning a new EDITOR for God’s sakes. Of COURSE there’s going to be a learning curve.”

I had written off the entire sorry affair.

A few weeks ago, Carl told me that he was playing with Vim. His explanation was that he had seen a number of people be really productive with it, and he was curious. Carl is definitely willing to put up with more pain to learn something new than I am, so I issued the same challenge to him.

Perhaps because he wasn’t steeped in hardcore vim hacker lore, he didn’t angrily dismiss the entire premise of my question. Thinking about it a bit more, I realized that most of the people who had tried to get me into vim had suggested that I dive in head first. “First thing: turn off the arrow keys.” “Don’t use the mouse. Force yourself to use the keyboard.”

Carl convinced me to use vim for the first couple of days pretty much exactly as I use Texmate (with the exception of having to switch between normal and insert modes). I installed NERDTree on MacVIM, grabbed the most common vim “packages”, and was off to the races. (I should note that I installed topfunky’s PeepOpen, which definitely helped with a very common workflow that I find it hard to live without).

For the first day, I clunked around by using my mouse’s scroll wheel, clicking and highlighting things, and spending most of my time in insert mode. It was slightly less productive than Textmate, but mostly in the range of what I’d expect switching to a new tool. In short, while I felt a bit out of sorts, I was able to get plenty of work done that first day.

As the days went on, I learned a few commands here and there. The first big one for me was ci as in ci " (it means: replace what’s inside the next set of " and go into insert mode). This singlehandedly made up for most of the productivity losses I was feeling from learning a new tool. Throw in o, O, A, :N and /search and I was already quite a bit more productive than I had been in Textmate.

Sure, I’m still plodding around in some cases, but only a handful of days later, using Textmate for anything feels clunky (most commonly, I try to use o or O to insert a new line above or below the one I’m currently on).

I was able to get here because I used my mouse wheel and button, arrow keys, apple-f to find text, apple-s to save files, and a whole slew of other common idioms, instead of grinding to a halt and trying to switch all of my practices at once.

To those who would say “that’s obvious; of course you learn vim incrementally”, I would simply say that having spoken to a number of vim users in the past, I never got that advice. Instead, I got a lot of advice about turning off my arrow keys, disallowing the use of the mouse, and learning the (MORE EFFICIENT!!!) vim ways to do everything, all at once. People just couldn’t stomach the idea of me continuing to use an outmoded practice (like apple-f) when vim had much better tools available just a (huge volume of) memorization away.

To those who are considering using vim, my recommendation is to use MacVIM, NERDTree, PeepOpen (or command-t), and use the mouse, arrow keys, and familiar OSX’isms all you want. Very quickly, it will become obvious that there’s a better way to do all kinds of things, and you can pile on the newly found efficiency once you’ve successfully made the switch without losing the ability to do work in the short-run.

Rails and Merb Merge

Today is a fairly momentous day in the history of Ruby web frameworks. You will probably find the news I’m about to share with you fairly shocking, but I will attempt to explain the situation.

Before talking tech, and even going into the details of the announcement, I want to assure everyone that the incredible members of the thriving Merb community are top priority, and that this could not have been possible without every one of them.

Merb is an open, ever-changing project, and some its best ideas have come from not-core regular-Joe community members. It’s gotten where it has because of the community, and the community will get us even further in the future. Your ideas, feedback and even complaints will be 100% welcome in the future, just as they have been in the past. I believe in the tremendous value an open community and just generally open attitude bring to the table, and am counting on those things to continue ushering in the future of Ruby.

On to the news: beginning today, the Merb team will be working with the Rails core team on a joint project. The plan is to merge in the things that made Merb different. This will make it possible to use Rails 3 for the same sorts of use-cases that were compelling for Merb users. Effectively, Merb 2 is Rails 3.

What does that mean exactly?

  • Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. We will focus on reducing coupling across Rails, and making it possible to replace parts of Rails without disturbing other parts. This is exactly what Merb means when it touts “modularity”.
  • We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins. This project will also include the creation of one or more benchmarking applications, so we can more clearly see what optimizations have real-world impact.
  • As of Rails 3, Rails will have a defined public API with a test suite for that API. This was one of the major differentiators of Merb. This will allow users and plugin developers to have a clearer, more stable API to build against. It should also significantly reduce plugin breakage from release to release.
  • Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
  • Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. While ActiveRecord will ship as the default ORM, the plan is to make it drop-dead easy to drop in other ORMs without feature degradation (to the extent possible, of course).
  • Rails will continue their recent embrace of Rack, which is a really exciting development in the Ruby community that Merb got in on early and which we believe will improve the state of modular, sharable logic between applications.
  • In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

How will we do this?

The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.

In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.

To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past.

If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.

Why!?

As you have probably gathered from the above, there aren’t any clear points that the Merb and Rails team disagree on anymore. Merb has been around for roughly two years now, and we’ve proved out our ideas by use in real-world applications (like Yellow Pages, SproutCore, Powerset, Defensio, etc.). Given this philosophical convergence, it just didn’t seem like there was much to gain by continuing to duplicate effort and spend time and energy fighting each other.

I think it’s important to acknowledge the Merb community for building something super-awesome. I really hope that we’ll all stay in this together, help each other in the coming months and in the transition to Rails 3.

Rails will be putting together a new evangelism team, which will include Matt Aimonetti (Merb core team member and evangelist) and a few other people doing Rails evangelism work. This group will be responsible for, among other things, helping the community get where we’re going. Their job will be to listen to you.

This seems crazy! Has this ever happened before?

Interestingly, yes. A very similar situation confronted the Struts developers several years back. They had built a very popular framework in Struts, but a very active group of developers were really advancing the same ideas in interesting ways in a framework called Webwork. The Webwork developers saw their project as “Struts done right”, just as we believe we’ve improved on the implementation of Rails.

Eventually, the Struts guys and the Webwork guys came to the conclusion that they would be stronger together then apart, and merged the projects. What became Struts 2 was effectively also Webwork 2, but the two communities got together to build something better.

I believe that this merger will get the ideas that gave Merb momentum into the hands of many more people, and that really serves us all. I’m looking forward to the future.

Postscript

  • One of the most personally gratifying parts of working on Merb has been working with alternative Ruby implementations to make Merb run well on them. Fairly early, Merb was running faster on JRuby than MRI, and I’m looking forward to bringing a lot of that insight to Rails, and helping to make Rails to be solidly competitive on the performance front with frameworks in “faster” languages.
  • The Merb Training is very much still on! We’ve spoken with the majority of the attendees, as well as with our partners at Integrum Technologies and they’re all really excited about the merger. That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. There are still a few seats open, so sign up now if you’d like to join us!

Textmate gem

As I said last week, I created thor while building a binary to handle my textmate bundles.

I wanted a way to install/uninstall/list textmate bundles like gems. Textmate already has a centralized svn repository for its bundles, and there’s a way, through AppleScript, to tell Textmate to reload bundles. The end result: a textmate binary that handles textmate bundles like gems.

$ textmate remote

Marcomates Trunk Remote Bundles
-------------------------------
ANTLR
ASP
ASP_vb_NET
ActionScript
Active4D
Ada
Apache
AppleScript
Bison
Blogging
Bulletin Board
Bundle Development
C++ Qt
C
CSS
CTags
CVS
ColdFusion
Context Free
D
Darcs
... snip ...

$ textmate remote JavaScript

Marcomates Trunk Remote Bundles
-------------------------------
JavaScript MooTools
JavaScript Prototype & Script_aculo_us
JavaScript YUI
JavaScript jQuery
JavaScript

Marcomates Review Remote Bundles
--------------------------------
JavaScript JSDoc
JavaScript MooTools
JavaScript Prototype & Script_aculo_us
JavaScript

$ textmate list

Application Bundles
-------------------
ActionScript
Apache
AppleScript
Blogging
Bundle Development
C
CSS
... snip ...
User Pristine Bundles
---------------------

User Bundles
------------
RSpec
Ruby Haml
Ruby Sass
Ruby
Rucola
Treetop

System Pristine Bundles
-----------------------

System Bundles
--------------
Ragel

$ textmate install

Checking out JavaScript jQuery…
svn co http\://macromates.com/svn/Bundles/trunk/Bundles/JavaScript\ jQuery.tmbundle /Users/wycats/Library/Application\ Support/TextMate/Pristine\ Copy/JavaScript\ jQuery.tmbundle 2>&1
A /Users/wycats/Library/Application Support/TextMate/Pristine Copy/JavaScript jQuery.tmbundle/Commands
A /Users/wycats/Library/Application Support/TextMate/Pristine Copy/JavaScript jQuery.tmbundle/Commands/Documentation for Word : Selection.tmCommand
A /Users/wycats/Library/Application Support/TextMate/Pristine Copy/JavaScript jQuery.tmbundle/Snippets
A /Users/wycats/Library/Application Support/TextMate/Pristine Copy/JavaScript jQuery.tmbundle/Snippets/each.tmSnippet
A /Users/wycats/Library/Application Support/TextMate/Pristine Copy/JavaScript jQuery.tmbundle/Snippets/clone.tmSnippet
… snip …
Checked out revision 9623.
Reloading Bundles…
Done.

$ textmate uninstall "JavaScript Prototype & Script_aculo_us"

Removing bundle...
Reloading bundles...
Done.

Pretty cool, huh? If you want it, do gem install wycats-textmate --source http://gems.github.com.

Textmate Search in a Folder (with grep) Part Deux

I posted my initial “Search in a Folder” solution a couple of days ago, and it turned out it had a few bugs (like the backgrounded ruby script never closing, and thus spawning a new ruby process for each time you loaded up the window. There were other user-experience annoyances, too. The good news is that that’s all in the past now.

The new version of the Wycats bundle has the following changes:

  • I am now using a utility window, so the search window always remains in front
  • I am now tracking open windows, so if you have an open window, another one doesn’t open
  • I track all available exit conditions and correctly exit the event loop
  • Other bugfixes and tweaks

Download version 1.0.1 today!

Proper Search in Directory

In August, I refactored a TextMate bundle to support Search within a folder via Grep. It was nice, but was fairly ugly, and non-configurable. Today, I’m releasing a (very alpha quality) version of a dialog that packages up grep within a directory into a nice GUI package (it looks a lot like Textmate’s default Search Within a Project dialog).

With this bundle, you can search within the entire project or any selected directory and get back the data in the bottom of the search pane, just like Textmate’s default search box. The bundle is activated by hitting Apple-Shift-F, but you can change it to whatever combination you like.

A couple of caveats

  • I don’t current block new windows from being created if one already exists. As a result, close your windows once you’re done with them.
  • Double-clicking a line in the bottom section of the dialog brings up the file with the caret on the line, as you expect. However, it hides the search window. Hit Apple-~ to get back to the search window. Hitting Apple-Shift-F will create a new window, so don’t do that.

Download the bundle today!

Search within a folder in Textmate

Ever wanted to search within a folder (or multiple folders) directly within Textmate? If you’ve ever tried doing full-project search, you know that it’s painfully slow. Thanks to Henrik Nyh, you can use grep instead of the built-in search, but his version only work on the full project. If you want, for example, to constrain your search to just the app folder in a Rails project, you’d have to make a new Textmate project, and search within there.

To simplify things, I expanded Henrik’s original work to support file contexts. If you select one or more folders in the project drawer, the search will be constrained to the selected contexts. If you select more than one context, the results for each context will be displayed sequentially, so you’ll see, for instance, all the results within the “app” folder and all the results within the “config” folder cleanly demarcated.

As with the original plugin by Henrik, this version does not support regular expressions, but it does return the results as clickable textmate URLs, which is nice. It also rebinds the apple-shift-f key, but you can easily change that if you want.

My updates are available as a bundle called “Wycats” — I hope to update this plugin to support regex as well as release additional useful items in the bundle.

Vibrant Ink Theme for TextMate

So the Vibrant Ink theme for Textmate has become a bit harder to track down lately due to some changes in EncyteMedia’s site structure.

Just to be helpful, you can download it from my blog

Archives

Categories

Meta