How do I use ellocale? Add instructions please!

[AndersonIsaac]

I am running vanilla Emacs (27.1), nothing fancy (no ivy, counsel, etc. (your package doesn't require them to work, does it?)), after installing ellocate with

(use-package ellocate)

configuring

(setq ellocate-scan-dirs '(("/home/" "~/.cache/ellocate-home-db")))

and finally running ellocate for the first time to scan

I type in a trivial search "ellocate-home-db" and it doesn't work (as I expected it to), instead ellocate creates an empty file "ellocate-home-db" in "/home/user/" (the folder from which ellocate was run).
Then I figured out that you are ought to hit Tab the first time so that ellocate autocompletes the "Find:" field with "/home/user/" and only then type the name of the file anywhere in the hierarchy below that path to search for.
I thought that your package was a full-fledged replacement for find-dired or find-name-dired (find-dired.el). Is it supposed to be only a "search as you type" thing? Are you familiar with fzf (fuzzy finder)? - It is much faster for that. With ellocate.el when I type in the search and hit TAB, the whole emacs session hangs (synchronous search??) for 4 or 5 seconds.

Now I have 3 questions.
Is there some additional configuration required to make this work?
Can you document ellocate.el better? - I and many other people would appreciate that.
Why aren't this package so popular (I found it by accident)? - The idea is superb though, hope I'd make this work with your help.

[walseb]

no ivy, counsel, etc. (your package doesn't require them to work, does it?)

No it shouldn't.

Then I figured out that you are ought to hit Tab the first time so that ellocate autocompletes the "Find:" field with "/home/user/" and only then type the name of the file anywhere in the hierarchy below that path to search for.

Yes, this relies on completing-read, which I believe by default doesn't show anything before you start typing. There is probably a setting for that somewhere or you can get something like consult or ivy which show all completions before you start typing by default.

I thought that your package was a full-fledged replacement for find-dired or find-name-dired (find-dired.el). Is it supposed to be only a "search as you type" thing?

You can turn it into a minimalistic dired by making the search then running embark-export from embark. From there you will only be able to filter down the search further using something like loccur or press enter which should open the file under the cursor. So you wont be able to delete or rename files I believe.

the whole emacs session hangs (synchronous search??) for 4 or 5 seconds

Yes this is the major problem with this package. Despite my efforts to optimize this it can still be very slow due to the completion system having trouble displaying 100 000+ entries. Disabling candidate sorting only gets you so far. The search can't be made asynchronous because of the synchronous nature of completing read. Also the actual search is super quick I believe, it's the completion interface that's slow. I experimented with asynchronous completions using the ivy interface and I believe I much preferred just typing my query while emacs was frozen to sitting and waiting for the asynchronous process to complete. I vaguely remember that the asynchronous process streaming in the results was also confusing as candidates would move around as the rankings changed. Also keeping it synchronous let me have less dependencies and the code is simpler.

Are you familiar with fzf (fuzzy finder)? - It is much faster for that

I believe the user can set up their completion framework to use fzf.

Is there some additional configuration required to make this work?

Nope

Can you document ellocate.el better? - I and many other people would appreciate that.

Yes I see now that the readme is misleading and not very well written. I will put it on my todo list.

Why aren't this package so popular (I found it by accident)? - The idea is superb though, hope I'd make this work with your help.

Thanks! I think most people are fine with just using find as its usually fast enough. I remember there being a lot of confusion between file name finders and file content searchers as well after I announced this package. Then there is the added complexity this package brings in terms of databases and such that can't be overlapping. Oh and the performance issues with massive folders.