Instead, you have to open the file in question and go find the method using one of the fiddly text-based methods that the article mentions.

So no, we're in agreement that the entire codebase belongs in your head. It's just nice to have your IDE also have the entire codebase in its head, in the actual configuration it is, rather than just knowing about a bunch of text files containing words that have no meaning to it.

>knowing that my codebase has half a dozen classes that expose a .hide member. I hesitate even to ctrl+click on it in this editor, because I know it'll either do nothing or take me to the wrong definition.

to mean you were relying on your IDE to tell you which .hide() method you were calling.

As others have pointed out elsewhere, I think giving that functionality to ST2 would push it too far into the realm of IDE.

  def spam(eggs):
      eggs.<TAB>

The same kind of global dataflow analysis would have to be approximate in a dynamic language, but I'd still expect it to be better than nothing.

    class A(object): def read(): return 'A'

    class B(object): def read(): return 'B'

    def doit(i):
        if i==1: obj = A()
        else: obj = B()
        return obj.read()

The same function can get called a 1000 times and take different paths each time. Which method is your hypothetical rewinding debugger going to show? (Leaving aside the big gaping hole of how your program is executing while you are typing it out).

The problem of deciding which method actually gets called by static analysis in a text editor (and it would have to be static analysis) is literally impossible for dynamic languages - pretty much by definition.

I see this type of situation as something that shouldn't happen very frequently.

Also, you could take this one step further and have it split screen the methods in multiple files if you like.