Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

On Thu, Nov 24, 2022 at 3:01 AM Dmitry Gutov <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 could
> >> 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.
I can't understand what is discourteous about this.


> I'm imagining that traversing a directory tree with an arbitrary
> predicate is going to be slow. If the predicate is limited somehow (e.g.
> 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.

João

[-- Attachment #2: Type: text/html, Size: 2529 bytes --]