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: Sun, 27 Nov 2022 18:09:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 26/11/22 21:23, João Távora wrote:
On Sat, Nov 26, 2022, 12:30 Dmitry Gutov <dgutov@yandex.ru <mailto:dgutov@yandex.ru>> 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.

Attachment: project-vc-extra-root-markers-and-subprojects.diff
Description: Text Data


reply via email to

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