On 26/11/22 21:23, João Távora wrote: > On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > wrote: > > > > My use case is the following: I'm interested in being able to > designate > > projects (through various means, not only marker files) that may only > > exist inside other projects. > > You previously described your super-project and how you handled it > using > project-find-functions hook with a new element that looked for file > markers. Does this patch make that easier to do? Without writing custom > functions? > > > The example i gave did _not_ use file markers. Personally, I can't use > them. I need some elisp way. Please elaborate. Does it mean that those subprojects are chosen manually and don't have "packages.jon" or etc exactly (or that too many subprojects in that same project would, undesirably, contain the same files)? Would being able to set to absolute file names (directories) help? Or is that too awkward? Worst case, we could also add the new option from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85, the result see attached. > > I then want the C-x p family of commands > > to allow a choice of inner project or any of the associated > > super-projects. > > Please avoid mixing feature requests. I already said that "choice of > inner or outer" is out of scope for this, but it's easily > implemented on > top. > > > What good are sub and super projects without a way to take advantage of > them? If anything we should focus on the operations first. As I have demonstrated, the features are orthogonal. Let's do it piece by piece, otherwise this bug might stay open another couple of years. > I have not seen your other patch. I take it it must have had some > drawback since you superseded it with something else. But post the link, > this thread is too long. I'll look at it on Monday if I have time. That would be https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85 The downsides we have already discussed: having to customize every "super" project individually is a pain, people more often seem to prefer to use "markers", the set of which is customized once. So we have to support "markers" anyway, hence it makes sense to try to make do with them only. But here's how it would look if we try to support both approaches.