Re: Subprojects in project.el

[Dmitry Gutov]

On 26/11/22 11:42, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 26/11/22 02:37, João Távora wrote:
> > > Dmitry Gutov <dgutov@yandex.ru> writes:
> > >
> > > > > > > I can't understand what is discourteous about this.
> > > > > > That would be not following the procedure the maintainer has asked you
> > > > > > to follow.
> > > > > If that means silencing me on emacs-devel, then you're out of luck.
> > > >
> > > > Is that what you do when you ask somebody to use the bug tracker?
> > > I'll use the bug tracker when I think it's appropriate.  Let's not
> > > insinuate I'm some kind of inconsiderate delinquent for not moving the
> > > discussion there as you would want.  I'm not reporting a bug and I've
> > > politely declined your suggestion, so stop beating this horse.
> >
> > Must be nice to be the person who gets to decide what is appropriate
> > in any situation.
>
> As long as this list's maintainer doesn't object, I get to decide where
> _I_ post to, thank you very much.

I'll keep that in mind.

> > By modifying each and every command. I don't think it would be
> > appropriate for 'project-current' itself to react to the value of
> > current-prefix-arg.
>
> It's very unfortunate to modify "each and every command" unless of
> course you mean doing it via a uniform interface.
>
> I don't understand why these "project" commands that operate on a
> project don't befittingly take a PROJECT argument.  That argument's
> value could be interactively calculated from a
> project-read-project-maybe command that decides if and how to prompt.

Hysterical raisins.

But 'C-x p f' and 'C-x p g' call 'project-current' directly. What's that 
about some new command?

> > > > What's missing in the infrastructure?
> > > Not much, I would say.  But I think at least:
> > > * A way that I can add an element to project-find-functions that
> > >     understands that a super-project has been detected already in the
> > >     current search and proceeds to find sub-projects inside it.  This is
> > >     what I posted code for.
> > > * A way for M-- (or similar) to consistently affect all (or most) of
> > > the
> > >     operations in the C-x p keymap so that we can choose if the operation
> > >     operates on the super-project, if it exists.  Unfortunately some of
> > >     these commands (like project-find-files) already take a prefix
> > >     argument to mean different things.  But it's not too bad.
> > > * A new project type, similar to the '(transient . "dir") project
> > > (and
> > >     inheriting most of its operations) that also keeps a record of the
> > >     super-project found.  This might not be strictly necessary, but could
> > >     come in handy later for efficiency reasons.
> >
> > Sounds pretty complicated. See if the latest patch solves your
> > immediate problems just as well.
>
> In your patch to be cramming it all into the VC type (which the comment
> itself admits becomes "VC and etc.") and trying very hard not to create
> a new subproject type.  But if you did that you could easily e.g. reuse
> the super-project's ignore rules etc in the sub-project.

How does one "easily reuse the super-project's ignore rules"? Would the 
sub-project type be called "sub-project"?

What if one VC repository is nested inside another? What if one "plain" 
project is nested inside another?