Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It makes me sad that the best tools available for writing code in so many otherwise exciting languages are still resorting to text-based autocompletion. And blogging about it as though it's something to be proud of.

This is certainly a pretty editor. But at its heart, it's still a text editor. And what I do for a living is edit code.

Code has a lot more information about it than text. I can imagine looking at a line such as:

  item.hide()
in this editor, 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.

In a perfect world (and in IDEs for statically typed languages since 1998), the editor would know exactly which .hide we were talking about. And it could gracefully send me there with a single click or keystroke.

I'm still waiting for something equivalent to appear for the Ruby/Python/Javascript portion of my world. But years keep ticking by and the best we get is text editors that try to guess by looking at text.

Maybe next year.



For C and C++, the sublime text plugin 'sublime clang' ( https://github.com/quarnster/SublimeClang ) , does exactly this, as well as check code for errors as you type. I only started using it a couple of days ago, and I already can't imagine being without it.


At least from my experience working in Python, if you don't know which instance `item` is, it's a problem with your code— not the editor. Automatically taking you to that class's method is another story, but I don't think you should depend on your IDE to figure out your logic for you.


Ah, but the issue isn't you knowing which 'item' you're dealing with. It's that the IDE doesn't know, and therefore can't jump you there instantly if you ask it to.

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.


I suppose it was a misunderstanding. I took this

>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.


What about parameters to functions?

  def spam(eggs):
      eggs.<TAB>
Should autocompletion go find all callers of spam() and see what they are passing in in order to determine what should be available at that point?


Why not? IntelliJ can do exactly that for Java code -- right-click on a variable and choose "dataflow to here". Even in large projects, it's practically instantaneous. Of course, in Java you don't need that much information for autocompletion since you can just look at the static types.

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.


Seems to me that the ducked-typed nature of Python makes it pretty much impossible to determine this information in a text editor.

    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()
When you put your cursor over the .read() in obj.read(), where does it point to?


You're not thinking big enough. Imagine a rewinding debugger that records a complete execution of your program. Then whenever your cursor moves, the debugger could step to a point when that line of code was executing and give you autocomplete suggestions based on the state of the program at that time.


Doesn't solve the problem.

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.


You are far too pessimistic; a few very simple heuristics would work great in most cases. It doesn't have to be perfect. Something imperfect would be miles better than nothing, which is what we have now for dynamic languages.


how about just a popup box that lets you choose where you would like to go?

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.


That just reminds me of Steve Yegge's rants.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: