|
From: | Nikolay Kudryavtsev |
Subject: | bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project |
Date: | Tue, 5 Oct 2021 21:19:21 +0300 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
So it all makes sense so far, at least conceptually. But here you're saying "you should not add a new file-based backend until you really think about the project file list optimization first". This violates the classic rule of doing the right thing first, then optimizing second. So while I feel this a real issue, it IMHO should be filed and discussed separately and is a nonblocker for this particular task.
Now to contradict myself, lets continue discussing this issue. I think this is a local version of a more global multiple backends problem. Lets say we have the same project(more precisely, a set of files) that is served by multiple backends. Roughly we order project-find-functions in this order: major-mode backends, tool backends(eg. GNU Global), generic backends(VC). The preference for the major mode backends over others is due to that "VC has different root" use case. Tool backends are preferred to VC due to that you can start a new Global project as sort of a custom project hack.
And here we run into the problem: our major mode while it provides a backend, does not optimize file listing, but there's a backend that does. I think TRT is project.el choosing a different secondary backend in this case as long as it has the same project root. For this it needs to have some rules, to know which backend better fits a particular situation, which does not.
This would require a change of backend registration, since you can't just have one function, so in the end the api would look something like this:
(register-project #'my-project-find-function :optimizes-file-listing nil)
[Prev in Thread] | Current Thread | [Next in Thread] |