[DavidWoof]

I don't think this point is about configuring your editor/environment as much as just knowing it. There's certain features that come up all the time: find file, find class, go to implementation, find references, rename var, etc.

It stuns me how many devs do this stuff manually, when virtually all editors/ides have ways of doing these things.

[darby_nine]

In some ecosystems, the tooling is just not that good. To use ruby on rails as an example: if you lean into the IDE's expectations for code layout it works ok, but there will always be generated methods and variables with nothing to show but the name—no documentation, no source, no googleable identifier, nothing. In these cases there's nothing to do but pull out the rails (or library) source to try and discern their intention.

In my experience, lisp also has this issue of being very difficult to tool in a general sense, as did aspects of writing c/c++ years ago (maybe recognizing stuff like macro-generated symbols has improved by now).

[skydhash]

> lisp also has this issue of being very difficult to tool in a general sense

Most of the common lisp tooling is already present in the language itself. Things like inspect, trace, describe and apropos already gives you the equivalent of most IDEs. I agree with you for some dynamic language and magic methods. It can be hard to trace back the exact function that are being called. But you can always design some tooling for it as long as the code follows the ecosystem convention (Laravel plugin in PhpStorm).

The nice thing about Vim (and other configurable editors) is how easy to mesh existing tooling with the editor itself, without requiring for that extension to be a whole project unto itself.

[Chris_Newton]

This is a disadvantage of the more dynamic languages, I find. IDEs for languages like C++ and Java are relatively fast and accurate when jumping to definitions, showing references, performing automated refactorings and so on. I rarely see that same precision for any editor or IDE working with TypeScript, Python, and other very dynamic languages, even with the improvements recently thanks to LSP and generally better tools. When almost anything could theoretically have been patched at runtime — even if doing so would be a terrible idea and every style guide says don’t do it — it’s not safe for tools to make the same kind of assumptions with the more dynamic languages that they can with the more static ones.