←back to thread

Bare Metal (The Emacs Essay)

(waxbanks.wordpress.com)
197 points hpaone | 1 comments | | HN request time: 0s | source
Show context
billfruit ◴[] No.45653702[source]
While I still use emacs, I find that that despite the "batteries included" narrative about emacs, the things which are not included are causes of major frustration.

Such essential functionality like grep-find and LSP servers which is required for out of the box auto complete are not bundled with emacs. Most modern IDEs/editors have these functionality baked in.

If you install emacs for windows you find that grep-find doesn't work, because it depends on support from environment. A full text search should be built into the editor.

replies(13): >>45653816 #>>45653935 #>>45654013 #>>45654310 #>>45654657 #>>45654749 #>>45654984 #>>45655041 #>>45655085 #>>45655291 #>>45655623 #>>45656821 #>>45682752 #
kragen ◴[] No.45655041[source]
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.

replies(1): >>45656767 #
PaulDavisThe1st ◴[] No.45656767[source]
To be fair, running grep from Emacs is a mistake - you should be using ag, or some other parallelized version of grep :)

Ardour has around 800k lines of code, and ag (not even the fastest of the new greps) can search it all more or less faster than I can type.

The idea of some system that analyzes/caches/indexes the code just isn't necessary anymore.

replies(2): >>45657454 #>>45661124 #
paddy_m ◴[] No.45661124{3}[source]
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!

replies(2): >>45661706 #>>45665988 #
rrgok ◴[] No.45665988{4}[source]
Would you mind sharing how you did the prioritization of the sources when searching?
replies(1): >>45667110 #
1. kragen ◴[] No.45667110{5}[source]
Not the original poster, but if I were doing it with find rather than fd (or ag or rg, which I think can do it without fd or find) I'd do (untested)

    (find "$projroot" -name .git -prune -o -name node_modules -prune -o \
         \( -name '*.[tj]s' -o -name '*.[tj]sx' \) -print0 ;
     find "$projroot"/node_modules \
         \( -name '*.[tj]s' -o -name '*.[tj]sx' \) -print0 ;
     find "$projroot" -name .git -prune -o -name dist -prune -o \
         \( -name '*.py' \) -print0 ) |
    xargs -0 grep /dev/null "$search_pattern"
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.