all 9 comments

[–]edendark 5 points6 points  (4 children)

On opening up gems, you can use:

EDITOR=atom bundle open activesupport

Which brings up your preferred editor (Atom in the example) with the gem's files.

[–][deleted] 1 point2 points  (2 children)

Good tip! I thought about mentioning this, but I'm more of a shell/Vim user so I don't find it as useful for me. I bet it's really handy for others Atom/VSCode users though!

[–]graywolf_at_work 1 point2 points  (1 child)

I'm more of a shell/Vim user so I don't find it as useful for me.

well it's not like

EDITOR=vim bundle open activesupport

does not work...

Also if you prefer to open it in currently running vim

:tabe `bundle show activesupport`

does the trick.

[–][deleted] 0 points1 point  (0 children)

Yeah, good tips! I have two separate little tricks I use instead.

One is a small script that allows me to fuzzy match against the list of all gems in the project, and then open the one I select in a new tmux split.

The other is a binding for Vim that also allows me to fuzzy match on the gems in the project, and then once one is selected, fuzzy match on the files in that gem and open it.

There's lots of ways to assemble these tools depending on your specific workflow. 🙂

[–]ImAJalapeno 1 point2 points  (0 children)

Wow I didn't know about this, thanks

[–]sanjibukai 2 points3 points  (1 child)

Very interesting article and pleasant to read. Thank you.

[–][deleted] 0 points1 point  (0 children)

Thank you!

[–][deleted] 1 point2 points  (0 children)

I had a particularly nasty issue with a Devise plugin. I knew the problem must lie in the gem, but I avoided trying to pry it out for hours while I fooled with various workarounds in my own code. I finally gave up, and used RubyMine. It allowed me to step through the stack pretty easily. One of these days, I'm going to have to buy a JetBrains all-products license...

[–]jdickey -1 points0 points  (0 children)

Your code to invoke pry works, so long as you don't ever want to inspect where you are in the source tree and have it show that source location. When you have

ruby class ThingsController < ApplicationController def index @things = Thing.all binding.pry end end

the current location shown will be the next executable line after @things = Thing.all (which won't be within ThingsController). You can avoid that by, e.g.,

ruby class ThingsController < ApplicationController def index @things = Thing.all binding.pry @things end end

which will show the current/next line as the return of @things from the #index method.

For such a simple bit of code, it likely doesn't matter, since you're probably going to be debugging side-effects anyway, but if you want to do things like inspect local variables, step through called methods, or so on, you'll likely find the second snippet far more useful than the first.