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: Dmitry Gutov
Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project
Date: Sat, 26 Nov 2022 14:29:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 26/11/22 11:52, João Távora wrote:
Dmitry Gutov <dgutov@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.





reply via email to

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