Hacker News new | past | comments | ask | show | jobs | submit login

Yeah especially compared to interrupting the editor, grepping code, parsing results getting back in, opening file and line number.. Find in files/project in Visual Studio makes that so much faster, also you can easily jump through all results without ctrl z and fg thousand times.

Versus a single hotkey press. Where is the context switch? :)

I use the first workflow myself pretty often, only with vim, because I work a lot per SSH. And it is just massively slower.




The single hotkey press is virtually never applicable though. If all you need to do is navigate to the definition, after the single first time you find it, it’s a matter of ctrl-b <file> enter.

At least in my experience, 99.9% of the time, I need a fast and organized way to see all the places where something is used or mentioned. The one special case of the definition is only a super tiny fraction such that the difference between a hotkey or an emacs key combination is utterly meaningless.

I do also think that being transported to some location of some file is a context switch that requires you to stop and think about where did the hotkey take you, what part of the source tree, what else is there.

When you git grep and open a file of your choice, the experience is just different. The path there aides you in understanding what to look for or do, at virtually no extra cost because it’s so fast and easy even in large codebases.

Maybe there is some slight benefit of the IDE handholding and hotkey approach in a codebase you literally never looked at before during the first few times you search for something. But that “burn in” effect isn’t enough to offset how the UI gets in the way, features that have to be accessed by menus or clicks, inevitable failures of integration with linters, compilers, or runtime programs.




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

Search: