I've never used grep-find or LSP, despite using Emacs for 32 years. Maybe I should; is grep-find better than M-x grep?
Apparently I've sometimes improvised an equivalent: "Run grep via find, with user-specified args COMMAND-ARGS. ...
This command uses a special history list for its arguments, so you can easily repeat a find command."
My out-of-the-box autocomplete is M-/, which works in environments where LSP doesn't, like writing English. It works sort of poorly in all of them, but I write production code slowly enough that my typing speed isn't close to being a bottleneck. It's more of a bottleneck when writing English, but even there, generally any of my good writing was good rewriting.
Where I've found LSP-like functionality really useful in the past in IDEA and later Eclipse was not autocomplete, which is mostly an annoyance, but in automated refactoring (extract variable, extract method, inline method) and in rapidly iterating through the implementors of a method whose semantics I'm changing.
That seems reasonable, yeah. ripgrep, etc., are definitely faster.
Somehow I never twigged that you wrote Ardour and JACK. Thanks for JACK! (My audio editing needs are very modest and so I haven't actually tried Ardour.)
I customized grep-find on my setup. I have a shell script so that it does the following (in typescript-mode)
first search ts, tsx, js, jsx files in the current project. Exclude .git, node_modules...
then search node_modules with the ts.. extensions, still exclude .git
finally search the whole tree for .py files still exclude .git, /dist...
This is coupled with consult-find-grep. I basically want to find a string in the most relevant file type. I never want a result from node_modules first in the results. It took some work, but the results are quite nice!
Oh, yeah, I wrote some Emacs Lisp that did that kind of project-specific thing for a Perl project I was working on for a couple of years in 02003 and 02004. One function key would search the whole project for occurrences of the identifier under the cursor, and another one would search for definitions.
And, although that approach does work (and maybe even that script will work without any bug fixes) it probably goes a substantial distance toward showing why fd was written.
Doing the three searches separately and exiting after one succeeds is only slightly more code.
Apparently I've sometimes improvised an equivalent: "Run grep via find, with user-specified args COMMAND-ARGS. ... This command uses a special history list for its arguments, so you can easily repeat a find command."
My out-of-the-box autocomplete is M-/, which works in environments where LSP doesn't, like writing English. It works sort of poorly in all of them, but I write production code slowly enough that my typing speed isn't close to being a bottleneck. It's more of a bottleneck when writing English, but even there, generally any of my good writing was good rewriting.
Where I've found LSP-like functionality really useful in the past in IDEA and later Eclipse was not autocomplete, which is mostly an annoyance, but in automated refactoring (extract variable, extract method, inline method) and in rapidly iterating through the implementors of a method whose semantics I'm changing.