On 20.11.2022 01:25, João Távora wrote:
> I had hoped to plug it in project.el but I couldn't find a way, so
> I rebound C-x p f to it.
Should be easy enough: you create your own backend (rather than reusing
'transient') and override the generic 'project-files'. Then add it to
project-find-functions.
iiuc project-files should return a list of files, or can it return a completion table as well? If not the latter, then i think it won't work...
Yes, sorry for the confusion. I'm not sure how feasible it will be to use a completion table instead, it's something to look into. E.g. it would need to perform the conversion in project--read-file-cpd-relative lazily.
In my usage, though, project-find-file shows all available files right away, so it's a question whether the lazy computation will actually speed things up. Maybe if you require non-empty inputs only? And two chars or more? But what happens when you backspace and type again? The indexer rescans the directory? Unless such scans use a very fast index, just reading the whole list of files into memory can be faster.
Anyway, this is the problem with the popular recommendation: just add a
thing to 'project-find-functions'. It degrades performance and changes
how project commands work too.
I don't see the relation. If anything this reduces the amount of files to search (but it's still a lot).
It switches to a less efficient indexer ('find'), and it drops the handling of .gitignore. So, listing all files in a 100'000 file subproject might take longer than listing all files in the parent 400'000 file project using 'git ls-files'.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4