4 ms·
> I use Emacs and I never want autocomplete or "go to definition" features. I hate them. In the cases when I unfortunately need them it's a symptom of exception
by girzel 8y ago
> I use Emacs and I never want autocomplete or "go to definition" features. I hate them. In the cases when I unfortunately need them it's a symptom of exceptionally bad software
I can understand wanting to be able to code without these features, but I can't understand "hating" them. I use "go to definition" not because I can't find a function definition, but because it gets me there faster. What's the moral advantage of opening a file and searching, vs hitting "M-."?
- mlthoughts2018 8y agoIf you're just talking about the first time you need to open the file, then sure, who cares. But I'm talking about the typical way of working when I have multiple files open and move between them or place them into multiple Emacs windows. In that case, it is SO much faster to jump based on knowing which file I intend to move to, rather than moving to a file because it happened to be the file that contained a given definition. If I have to think, "go to wherever function X is defined" that's a drastic mental slowdown compared with "C-x b <file where I already totally know where function X is because of the code structure>". It's similar with autocomplete, even for very long names. I am fast at typing, so the little disruption of needing to enter a visual scan mode to select the right entry from e.g. some JEDI autocomplete option is a huge time cost for me added up over all the times I would write out e.g. function or class names in my code. They are both the sort of thing that superficially sounds like it would save you time or cognitive load, but they don't, unless you happen to be in the pathological codebase scenario I was describing and you need the tools because the project's code organization does not permit being able to reason efficiently about it from local mental caches.
- DatBear 8y agoI'm not sure what code completion you're using, but if it's contextual, I'm very lost as to how typing a ridiculously long name would be faster than auto completing it. Especially since once you're used to the auto complete, you can basically use shortcuts for specific things you're using in that context a lot. "BindingOperations.EnableCollectionSynchronization()?" oh, that's "bop.ecs". There should be very few options to pick from unless everything is very similarly named...
- seandougall 8y agoI also find autocompletion invaluable when I'm working with an API I don't interact with regularly enough to have everything memorized, mere mortal that I am. I might not remember exactly what naming convention the methods conform to, or what order the arguments need to be in, and autocompletion gets me both of those essentially for free, without having to pull up the docs for every method call.
- mlthoughts2018 8y agoI can agree with this — if you’re really working on a codebase that you rarely interact with, then sure, “jump to” and autocomplete features are helpful. Over my career, the relative amount of time spent doing that is really tiny though. It doesn’t invalidate the value of autocomplete or “jump to” features for this use case, but for me it’s not common enough to matter a whole lot. Other forms of searching work just fine too. My other comments are written regarding the case when you’re hopping around an in-house codebase, and beyond some initial burn-in, you should have a lot of working knowledge of the details.
- mlthoughts2018 8y agoIt wouldn’t matter if the auto-completion only had one option to pick from. The visual disruption of needing to see that and hit enter or arrow down is already a time loss compared with just typing the thing.