Kind of? Text search will also find commented out usage, docu, changelog, and my .org file with refactoring ideas from last month. (For better or worse.) It will also show when a class with the same method names exists elsewhere - which you want to know about if the naming is good. To find usage of a method called "update", LSP results will be better, but... that was kind of the point? That you don't name your methods "update" if they are important semantically.
And rg also works in projects with multiple programming languages (e.g. you're using a method from JS and want to find its Rust implementation in the webassembly module) and across project folders (instead of pointing you to a read-only copy of an installed module). But, if you spend 95% of your time in a single codebase with a single language... YMMV.
> Text search will also find commented out usage, docu, changelog, and my .org file with refactoring ideas from last month
Yes, when searching across the entire project for text an instant fuzzy search is an invaluable tool.
> It will also show when a class with the same method names exists elsewhere
Oh, this is a great example when a code-aware tool is better. I also ave a rant-ish about LSP at the end.
So, let's say you have several methods called `update` across your codebase. As per original comment, "I rarely need to find only the definition of a function, but rather other call sites too".
With text-search you will find all those other methods, and all the call sites for those methods. And not just in the working code, but across all tests as well. So you have to manually go through the search results and figure out whether a call to update is the one you're looking for.
Of course all that is also integrated with things like refactoring. So if you rename a method, you don't have to painstakingly manually search for all invocations of that method. Or if you rename a parameter to that method, or... See the several dozen possibilities here: https://www.jetbrains.com/help/idea/refactoring-source-code....
----
Here comes the rant.
The whole "text searching is enough, the compiler will pint to me the errors I've made" fashion has held back tool development by several decades. It's telling that LSP (which has barely 5-10% of IDEA's functionality) has taken this world by storm. Suddenly the languages and the editors that lacked even the basic quality of life improvements when working with code got a glimpse of what is possible.
Welcome to the very early beginning of the 21st century. Perhaps in 20 more years you will finally let go of the notion that painstakingly doing a computer's job is not in any way or form productive or indicative of a great programmer somehow [1]. And that to work with code you really want tools that are capable of working with code.
After all, somehow, you reach for Excel/Numbers/Google Sheets to work with spreadsheets, for Photoshop/numerous alternatives to edit photos etc. You don't reach for some generic vaguely-adjacent tool to do the job.
[1] I keep telling this story: About 5 years back I saw several people switch from vi/emacs to PHPStorm/IDEA after watching me zipping through code (including jumping from Symfony configs to code and back) while they spent often minutes doing fuzzy searching through the codebase we were working at the time: a huge legacy monolith we were slowly refactoring and splitting up.
I'm glad you mentioned IDEA, so I didn't have to. People rave about LSP and it's great that it exists, but IDEA has been doing more advanced code navigation for years (decades?).
You seem weirdly angry that some other people like to work in a different way than you like to work. People like different things. You still get to like your thing.
I 100% use LSPs and other modern tooling, but I find it weird as well too. Like, if I found out a favorite author of mine wrote everything on paper first I'd find that amusing and quirky.
Obviously a developer not using LSPs can be competitive against someone who doesn't (though that's not always the case).
Though if someone is truly bothered by others tool preferences, they should take comfort in the thought that if things really are as they believe, then these people should be driven out of a job for failing to keep up with the times. "Great," you should think, "one less person of competition on the market."
There's nothing weird with being annoyed at people who not only have no idea about the tools available to them, but also make no effort to learn about them while patting themselves on the back for it and feeling superior
Isn't that you feeling superior because of your tool preference?
It's quite possible to know about a tool and still not like it. Some people liked microsoft's Clippy, and some other people didn't and it's hard to say that either of them were wrong in what made them moste productive, respectively.
> It's quite possible to know about a tool and still not like it.
My experience with people bashing IDEs has universally been: they've never tried them, or tried for at most a few days. You can immediately see in their comments.
Could be I was exposed to too many such programmers :)
Here are my issues with IDEs. Perhaps you can win me over.
#1. If I decide to migrate from 20 years in the shell with vim & friends, I only want to have to do so once for at least another 20 years and I don't want to use different IDEs for each language I use. I regularly do embedded work in C & aarch64|x86_64 assembly and write applications in both Java & Python. (Yes, I write Java in vim.) I've recently started working with hardware design in Verilog as well.
#2. I prefer to learn the tools I use very deeply, but I learned all of the ones I use now when I had all of the time in the world for yak shaving: high school and university. I have available to me now only a small fraction of the time which was available to me then, so the path to mastery should not be very steep.
#3. Intuitive keyboard navigation of the entire interface is a must. Jumping back and forth to using the mouse feels incredibly uncomfortable to me. It breaks my train of thought just like having an itch which comes right back after having just been scratched would.
#4. The IDE should not rely on an internet connection as I often develop on completely airgapped LANs.
And rg also works in projects with multiple programming languages (e.g. you're using a method from JS and want to find its Rust implementation in the webassembly module) and across project folders (instead of pointing you to a read-only copy of an installed module). But, if you spend 95% of your time in a single codebase with a single language... YMMV.