[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subprojects in project.el (Was: Eglot, project.el, and python virtua

From: Dmitry Gutov
Subject: Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)
Date: Fri, 25 Nov 2022 00:58:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 24/11/22 10:50, João Távora wrote:
On Thu, Nov 24, 2022 at 3:01 AM Dmitry Gutov <dgutov@yandex.ru <mailto:dgutov@yandex.ru>> wrote:

    On 23/11/22 15:57, João Távora wrote:
     >> It would be much more helpful in a dedicated bug report where we
     >> discuss the details, collect the votes and see what kind of design
     >> will ultimately satisfy the requirements. Instead of drowning it all
     >> in this thread, which is only moderately related.
     > I think we're doing fine here but I've changed the subject line to
     > "unbury" it from the thread.

    You're fussy about proper bug reporting in your projects, but
    somehow do
    not extend that courtesy to others.

I am indeed "fussy" about "bug reporting".  But here, Dmitry, I am not
reporting a bug.  There's no minimum reproducible recipe, no error
to report, no surprising behaviour, etc. to speak of.  We're just
discussing Emacs development... in the emacs-devel mailing list.

You are making a new feature request. Or at least were (when you were talking about "subprojects" as a new noun for project.el to have, with new associated behaviors).

Since we're back to examining customizable ways to mark projects, I invite you to read https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82 too.

I can't understand what is discourteous about this.

That would be not following the procedure the maintainer has asked you to follow.

    I'm imagining that traversing a directory tree with an arbitrary
    predicate is going to be slow. If the predicate is limited somehow
    to a list of "markers" as base file name, or at least wildcards), 'git
    ls-files' can probably handle this, with certain but bounded cost.

If the user wants marker files to mark the roots of subprojects, we'll
have to access the file system eventually because that's where
that information lives.  It would be a minimal and essential access.  If the
user is discontent with that performance hit (I really doubt it), then
the user may use other means to mark roots of subprojects, like
the one I suggested earlier.

In particular, I don't understand where "traversing a directory tree" comes
in.  That part is completely absent from the solution I am putting forth.

Your solution looks very similar to the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85, which see.

Note that I have replied to your solution as well with a couple of questions, related to what is already written in the bug above.

I don't really know what "the user wants". People apparently find this discussion too scary or meandering to provide any additional input. The several who I asked to comment have walked away perplexed. Or perhaps it's just Debbugs.

People do seem it natural to express their custom project structures via file markers, at least that's what I see in the wild as project-find-functions customizations.

They have an upside: it's economical to customize markers once, and then have them used for every project of yours, instead of having to edit dir-locals.el everywhere where needed. But the downside is that implementing the non-intersecting model of project becomes expensive: in the most general case one will have to traverse the dir tree to find the inner projects to exclude them. But if the markers are plain file names or wildcards, optimizations are possible (e.g. 'git ls-files'; which is still not instant, however), at least for Git/Hg parent projects.

The idea of customizing the projects with a list of relative subproject directory file names solves those downsides, but comes with lack of automation: you have to do it for every relevant project, and not forget to update the settings as the project structure changes. Which might also be a pain e.g. when switching branches, if your dir-locals.el is not checked in.

Perhaps we'll ultimately end up with both ways to do this inside project.el, but that feels redundant.

reply via email to

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