GNU bug report logs - #41572
28.0.50; [PATCH] Support plain project marked with file .emacs-project

Previous Next

Full log

View this message in rfc822 format

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Zhu Zihao <cjpeople2013 <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>, 41572 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project
Date: Tue, 5 Oct 2021 21:19:21 +0300

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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.