Re: Subprojects in project.el

[Dmitry Gutov <dgutov@yandex.ru>]

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?