[Top][All Lists]

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

Re: Subprojects in project.el

From: Dmitry Gutov
Subject: Re: Subprojects in project.el
Date: Sat, 26 Nov 2022 14:38:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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

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

reply via email to

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