Further important (to me) scenarios that also argue for greppability: - greppability does not preclude IDE or language server tooling; there's often special ca

Further important (to me) scenarios that also argue for greppability: - greppability does not preclude IDE or language server tooling; there's often special cases where only certain e.g. context-dependant usages matter, and sometimes grep is the easiest way to find those. - projects that include multiple languages, such as for instance the fairly common setup of HTML, JS, CSS, SQL, and some server-side language. - performance in scenarios with huge amounts of code, or where you're searching very often (e.g. in each git commit for some amount of history) - ease of use across repositories (e.g. a client app, a spec, and a server app in separate repos). I treat greppability as an almost universal default. I'd much rather have code in a "weird" naming style in some language but have consistent identifiers across languages, than have normal-style-guide default identifiers in each language, but differing identifiers across languages. If code "looks weird", if anything that's often actually a _benefit_ in such cases, not a downside - most serialization libraries I use for this kind of stuff tend to do a lot of automagic mapping that can break in ways that are sometimes hard to detect at compile time if somebody renames something, or sometimes even just for a casing change or type change. Having a hint as to this fragility immediate at a glance even in dynamically typed languages is sometimes a nice side-effect. Very speculatively, I wouldn't be surprised if AI coding tools can deal with consistent names better than context-dependent ones too; greppability is likely not specifically about merely the tool grep. And the best part is that there's almost no downside; it's not like you need to pick either a language server, IDE or grep - just use whatever is most convenient for each task.