10 Actions You Must Internalize in Your Editor

I say 10, but, it could well be 16. The point is having a minimum viable list.

We love our Emacs vs Vim vs <others> debates. In one argument Emacs rocks, in another Vim wins the day and in some other, TextMate takes the cake. However, more than we love our editors, we love being productive; after all that is all what this is about. By now, we know that the joy of writing code is well augmented by a good editor. It acts like a great force multiplier. We go to great lengths to curate the editor and it’s configuration to what suits us.

What happens when you want to use a different editor? Or the same editor with different dotfiles? They say that opening an editor and finding someone else’s dotfiles is like going to bed and finding someone else’s partener there. From the outset, looks like an extremely awkward and uncomfortable experience. But, great if you were looking to switch. So how do you learn an editor in order to be effective enough; enough being the keyword here? The short answer to this is “do the grunt work and put in the time”. However, I think all is not lost and learning a few actions as the first thing can save you a lot of time. I often keep cheat sheet ready with these actions in order to build the required muscle memory.

Now, this list is of course not complete. A lot of things could be added to it or removed from it. However, this is my recipe for quickly learning an editor. And I would love to hear yours. One thing to keep in mind is that this is not an exhaustive list of features that our editors must have. No. This is a list that we as programmers can use to quickly pass the learning curve of an editor.

  1. Navigation within the file, moving around. This is the most fundamental and the very first thing you’ll probably do. If in Emacs you can’t C-n C-p C-f or C-b your way around, you’ll feel exasperated soon. So first thing to learn would be move the caret forward and backward. There are different flavours to moving around:
    1. One character at a time
    2. One word at a time
    3. One line at a time
    4. One paragraph at a time etc.
  2. Select, cut, copy and paste. This comes naturally from Point 1. Once you are able to move around, you would want to move text around. Selecting text is also extremely important. You don’t have to use your mouse to actually select. Selection is actually demarkation, and it works a scope. Select a bunch of text and then perform an action only on that text. I’ll elaborate on this further down the list. <rant> This ability is overrated and often superceded by others actions in the list. </rant>

  3. Duplicate, delete, move and displace lines and blocks. When working with code, we often work with whole lines, rather than words or characters. Which is why this ability comes extremely handy. It is best used while refactoring code or formating code. I cannot stress how important this is. Duplicating lines and them moving them around is indispensible. Once you’ve learned to use this well, I’ll bet you would be uncomfortable without it.

  4. Search and replace strings and regular expressions; scoped or not. Search and replace, combined with text selection that acts as scope is an integral part of refactoring code. When I think of S&R, I think of renaming variables, functions, classes. I think of upgrading from :key => value to key: value. I think of upgrading from Bootstrap 2 to Bootstrap 3, where span12 becomes col-md-12. You get the point. As a side note, if you are building an editor to learn something new, this can a fun feature to implement. Go ahead and try if it suits you.

  5. Quickly generate boilerplate code. Once you are past the steeper part of the learning curve of a language technology, boilerplate manifests as the killer of you productivity and brings death to it by boredom. Unless, you have tuned your editor to snuff it out quickly. Type def<tab> and boom, you have a method definition placeholder. cla<tab> and you have class declaration, for<tab> you have your block ready. etc. etc. More than the terse languages like Ruby, Python, this will be more handy in verbose languages like Java, Objective C.

  6. Quickly jump to recently used files. Jump to any file within the project in few keystrokes. Command+T in TextMate Control-P in Vim etc. When working on a project, the impact this feature can have is tremendous. One of the best use cases is jumping to last file. I often find that I typically work with 2 files at a time ( Model and the Controller or The presenter and the view, the header and the implementation, Model and its Tests etc. ). So I need to be able switch to other file fast. In Emacs, C-x b <enter>, in TextMate Command-T <enter>, in RubyMine Command-e <enter> do the job quite fanasticaly for me. In fact, as a principle, I do not use editors where this isn’t possible or isn’t fast enough ( I am looking at you Eclipse and Netbeans ). Most editors who do this well allow you to perform “partial name search” i.e. searching for bdct will return *broadcast* amongst others. Folder scoping is also often allowed. i.e. searching for a/v/a/bdht can return app/views/admin/_broadcast.html.erb.

  7. See or edit different parts of the same file or vertical & horizontal split views. When jumping between the files is not enough, you need to be able to look at the files at the same time, or look at different parts of the same file. E.g. while editing markdown, you’ll want live preview on right. Or while writing a public API for your class, you’ll want to look at the private methods etc. In another case, you’ll want to open up a REPL on the side while you edit code and preiodically send code to the REPL for evaluation. Use cases are plenty and hence this is a part of this list.

  8. Dumb autocomplete. Your editor and you should know how to quickly complete words in the same file, words typed before, keywords in the current language (programming or not). C-\ in Emacs, Alt-/ in IntelliJ or Escape in TextMate are good examples of this. Fancy, code aware completions are heavily IDE dependent and very hard to get right. But dumb completions can be fast and very handy.

  9. Run a test or open a shell. I love my Ctrl+Shift+R in RubyMine where it runs the test I am curretly editing or the test file I am currently editing, depending on where my caret is. Same goes for Command+Shift+R in TextMate. In Emacs M-x shell opens the terminal within Emacs and use it often, for running tasks, creating files, git commits, etc.

  10. Comment and uncomment code. I contemplated whether this should be a part of this list and decided to keep it. When working on existing code, commenting and uncommenting can be extremely valuable.

Comments

Console Your Gems: Add REPL to Them

When you are working on a Ruby gem or a Ruby library ( why you would have a Ruby library that isn’t a gem is beyond me ), it is always often desirable to have a Pry session loaded with the gem your working on. In fact, I’ll go out on a limb and say that REPL driven development is a a must-do when writing libraries. REPLs are like ice added to your beer when it isn’t cold anymore, except this ice is made from the same beer.

A lot of gems ship with this functionality, but if not, it is extremely easy to add one. To avoid polluting every gem with our code, we can utilize the concept of Rake’s global tasks. Rake’s default source for looking at tasks or rules is the Rakefile and all files that are declared as source files in the Rakefile; typically *.rake files in your tasks folder, but this can vary depending on your project. However, rake also looks at ~/.rake/*.rake if we ask it to. So let’s create a file called ~/.rake/console.rake and add the following task to it:

1
2
3
4
5
6
7
8
9
10
desc "Open a pry (or irb) session preloaded with this gem"
task :console do
  begin
    require 'pry'
    gem_name = File.basename(Dir.pwd)
    sh %{pry -I lib -r #{gem_name}.rb}
  rescue LoadError => _
    sh %{irb -rubygems -I lib -r #{gem_name}.rb}
  end
end

And run our shiny new rake task:

1
2
3
4
5
  awesome_sauce git:(master)  rake console
rake aborted!
Don't know how to build task 'console'

(See full trace by running task with --trace)

Bummer! Let’s double check:

1
  awesome_sauce git:(master)  rake -T console

Nothing! What gives? Not a cause of worry, because this is the expected behaviour, and we have a failing test. Rake takes global pollution quite seriously, and does not load the global tasks unless asked to. So let’s ask rake to do so, by adding a -g flag. Because, you know, g for global:

1
2
  awesome_sauce git:(master)  rake -gT console
rake console  # Open a pry (or irb) session preloaded with this gem

And subsequently

1
2
3
4
5
6
7
8
  awesome_sauce git:(master)  rake -g console
pry -I lib -r awesome_sauce.rb
2.1.1 (main):0 >
# Just to be sure
2.1.1 (main):0 > ^D
  awesome_sauce git:(master)  cd ../secret_sauce
  secret_sauce git:(hush-hush)  rake -g console
rbx-2.1.1 (main):0 >

With this, I bow out and promise to come back with more palatable content later.

Edit: As Emil pointed out, pry uses the same trick in pry --gem#.

Comments

I Am Speaking at RubyConf India

India’s premier Ruby conference is happening at Goa this year, in the third week of March. This year, my talk proposal got accepted and I am up on day 1 at 2.30pm.

I’ve been digging into real time web applications for the last few months and SSE (Server Sent Events) and WebRTC caught my attention. Pusher, a fantastic service that allows you easily implement a pub/sub model in your application, uses SSE as a transport. And WebRTC is a recent addition to the fore. Well, not so recent, as Google open sourced it in 2011. A standard API is currently being drafted by the W3C.

These technologies allow two-way communication between server and client and you no longer have to depend on polling to update the clients. There are arguments that this breaks the hypermedia agreement, and is harder to scale than traditional stateless Request/Response style of serving web resources. I haven’t yet formed an opinion on this, because I am clearly blinded by the awesomeness and ease of using these technologies.

In my talk I aim to introduce the concepts to the audience and then follow it up with code examples and best practises. As most of the audience would be interested hear about Rails integration, I will cover all examples in the Rails context. If you are going to be there, do read the Wikipedia page of the involved concepts and then come to the talk, I am certain you will gain a lot more this way.

Oh and I forgot to mention, RubyConfIndia offers this awesome badge:

Comments

Hello, World!

Wikipedia tells us:

A “Hello World” program has become the traditional first program that many people learn. In general, it is simple enough so that people who have no experience with computer programming can easily understand it, especially with the guidance of a teacher or a written guide. Using this simple program as a basis, computer science principles or elements of a specific programming language can be explained to novice programmers. Experienced programmers learning new languages can also gain a lot of information about a given language’s syntax and structure from a hello world program.

Comments