bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emac


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

I currently have a very basic real use case on my hands. There's a particular programming language that has it's own project file type. Since it's a project type, it makes sense to plug it in as project backend. And then on top of this I can implement project target actions like build, compile and debug(this is actually another matter that probably needs to be implemented in(or over) project.el at some point, I'll probably open a discussion about it later).

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)






reply via email to

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