[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eglot, project.el, and python virtual environments

From: Dmitry Gutov
Subject: Re: Eglot, project.el, and python virtual environments
Date: Sun, 20 Nov 2022 01:40:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

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

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'.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]