Fuzzy Finding with Emacs Instead of Fzf
masteringemacs.org
masteringemacs.org
Sounds interesting. What I've done recently is open my vim in the folder that contains all the organization's repos (the ones I've cloned) and just run ripgrep inside vim to find examples or references to whatever I've seeking. Seems performant enough even without doing anything except letting ripgrep ignore git-ignored stuff (default behavior of ripgrep).
Projectile works OOTB with .git directories, so if you visit a git-controlled dir it's added to your projects. You can similarly specify other directories as projects by putting a .projectile file in them, and the contents of the .projectile file act as an ignore list.
So the workflow is work/myMonolith is the git controlled root, while I have work/myMonolith/frontend/.projectile and work/myMonolith/backend/.projectile. So I can use the project-scoped find file, grep etc. to inherently narrow the search space to that module. When I'd want to globally search, I'd use projectile-find-file (or grep, or whatever) on the myMonolith root.
Indeed, in my global git ignore, same with other workflow-specific stuff that nobody else at $WORK uses
I actually use a mix of both. Project.el being built in means it properly leverages the built-in completion stuff, which has a level of awareness for the types of things I search and gives appropriate icons and context information (see all-the-icons-completion[1] for details). I fibbed a little bit about my workflow - to switch projects and find a file I use this:
(defun project-find-file-from-projectile-project ()
(interactive)
(project-switch-project (completing-read "From which project?" projectile-known-projects)))
https://github.com/PuercoPop/.emacs.d/blob/9d0b99d332d619fe3...
There is the emacs-fzf package, icicles, and various other vertical completion frameworks, but I essentially want something that pretends to be fzf at the Emacs level, without having to spawn background shell scripts
There are some options outlined in the readme of fussy[1], which is a wrapper around them. There are some pure elisp ones, and some written in native languages (including fzf itself) interfaced with dynamic module (so FFI rather than subprocess). Does that qualify as Emacs level?
We lost that battle in the late 70s/early 80s. It has nothing to do with the open source world.
That’s all.
You've just invented a rudimentary and worse version of COM. (There are advantages in not limiting yourself to low-level tooling like ptys/pipes/sockets.)
A web-dev example might be that CSS, the language design, is not the same as the ever-growing and inconsistent set of properties that the browser uses to style documents.
I think it would have reduced composition in practice. Part of what you get out of "text as the universal interface" is tools that never heard of each other being able to work together. Because there's only a couple types: string, maybe number depending on the context, list (strings separated by spaces or newlines) and record (single line of a csv/tsv file), things can be kinda coerced into working together.
You could get this with a type system... if you restrict yourself to at the most advanced List<String>, Map<String, String>, but you've lost ~80% of your type system value. As soon as anyone defines a custom struct, only tools that have heard of that type (which, in practice, end up being tools specifically made to work with it) can use it. Just using text with a few conventions is a really high utility point on the pareto curve for basically zero work.
I could see some benefit in getting a system defined Path/URL type, but you'd really need to have a culture of sticking to built in types, and a system that offers types to cover basically every use-case.
I don't think C ABI gets you this. Passing structs across ABI boundaries is kinda iffy, especially if you're using a different compiler than the program was originally compiled with. And lord knows what non-C programs would try to do.
(And helm is far more advanced than fzf is, as far as searching)
I don't know if it's been given a name, but this new wave of (usually Rust) shell tools that are great and seem obvious in retrospect (fzf, rg, etc) strongly feel like they're doing exactly right what Emacs has "failed badly" at.
edit: And now that I think about it, the "failure of Emacs" thing feels a lot not going the old "Unix way, do one thing and speak text" ideals?
Living inside Emacs separates you from lots of "how everyone else does it" over time and is hard to integrate with "everything else" without TONS of work.
To avail yourself of the full power of Emacs, it demands more "difference from everything else?"
But for the Emacs fans who've had success, that work pays them back because they can bend the editor to an extremely bespoke workflow.
I'm unsure if it will work out for me long term but I can sort of see the appeal. No other tool even attempts to be what Emacs has become.
So yeah, it's different from every other approach I've tried. But there's a chance it will work for me. Jury's out, though, and I am only now realizing that I'm going to have to put more effort into hacking my workflow than with other things I've used (Kakoune, Neovim, sublime, etc)