Re: Subprojects in project.el

[João Távora]

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.

> 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.

>>> 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.

João