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: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: "Philip K." <philipk <at> posteo.net>, Rudi Schlatte <rudi <at> constantly.at>, Augusto Stoffel <arstoffel <at> gmail.com>, Zhu Zihao <cjpeople2013 <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>, Daniel Martín <mardani29 <at> yahoo.es>, Eric Abrahamsen <eric <at> ericabrahamsen.net>, Manuel Uberti <manuel.uberti <at> inventati.org>, Juri Linkov <juri <at> linkov.net>, Rudolf Adamkovič <salutis <at> me.com>, 41572 <at> debbugs.gnu.org
Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project
Date: Sat, 26 Nov 2022 14:29:56 +0200

On 26/11/22 11:52, João Távora wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>> Does this work for everybody?
> 
> I was pointed to this thread and asked to comment on this patch.
> 
> 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?

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

> I can't understand from the patch alone if it solves this case, but it
> seems that it doesn't come near.  If not for any other reason, I can't
> always use marker files.

Did you prefer the other patch in this report?

Or do you perhaps see an easy way to augment this patch to cover the 
remaining cases? Perhaps of project-vc-extra-root-markers also accepted 
absolute directory names, or if an additional variable did that.

> I do see that in your patch more and more things appeari under the
> existing VC type, which I think is growing too much.  The comment itself
> admits that "VC" becomes "VC and etc." -- this is not a good sign.
> 
> The patch seems to be trying very hard not to create a new project type.

That's called "tradeoffs". Previous patches, if you saw them, made 
different tradeoffs with different downsides.

> But if a new subproject type was created with a link to a previously
> found super-project.  One could easily e.g. reuse the super-project's
> ignore rules etc in the sub-project.

For us to be able to discuss the alternatives, you'd have to read the 
previous comments on this report. Or I guess you can post a reasonably 
complete and functional alternative patch and we'd discuss the tradeoffs 
there.

Previous Next

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