Re: Subprojects in project.el

[Dmitry Gutov]

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.

> > > > I don't really know what "the user wants". People apparently find this
> > > > discussion too scary or meandering to provide any additional
> > > > input. The several who I asked to comment have walked away
> > > > perplexed. Or perhaps it's just Debbugs.
> > > People seem to be contributin a healthy amount of information here.
> >
> > Yes and no. Nobody has bothered to comment on the messages in the bug
> > report, or on the patches in it.
>
> If they help the discussion, suggest you put your patches in a scratch
> branch and announce it here.  It's not much work for you, I suppose and
> personally I find it simpler than finding your patches and applying them
> to the right version.

I suggest people look at the patches where they are posted.

> > Note that it would also be possible to do through some other
> > means. E.g. using some command in Xref result buffer which would
> > filter by file names and hide the rest.
>
> *compilation* and *shell-command-output* are not in any kind of
> structured Xref mode where that hypothetical command would operate.
> Even if such a command could be devised, I don't find that don't find it
> a very good solution.  If one knows the where to look in, it's better to
> grep only one haystack instead of the whole barn just to throw away most
> of the needles.

Sure.

> > > Not all files that belong to the super-project necessarily belong to a
> > > sub-project.  Some of them _only_ belong to the super-project.n
> > Do the files that belong to a sub-project belong to the super-project?
>
> Yes: in my view they belong to both.  i.e. if you project-find-file in
> the super-project, you can find a file in a subproject such that a
> subsequent project command operates on the subproject.

Okay, good.

> > > Anyway, indeally I want these three main operations (find-file, grep,
> > > compile) to run in the inner sub-project by default.  By typing
> > > something more, like, say, a negative prefix argument, I want to be able
> > > to be given the possibility to operate on the super-project instead.
> >
> > See the 'project-parent' implementation I posted a couple of days ago.
>
> I've seen it.  In fact, I posted the same code earlier.  But how do I
> plug in that so that M-- C-x p f, M-- C-x p c, etc, etc make use of it?

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.

As you are aware, some commands already react to prefix argument, and 
some third-party ones might even handle the negative value. Let every 
command deal with UI; we can make a helper that will make the code much 
shorter anyway.

> > > > The idea of customizing the projects with a list of relative
> > > > subproject directory file names solves those downsides, but comes with
> > > > lack of automation: you have to do it for every relevant project, and
> > > > not forget to update the settings as the project structure
> > > > changes. Which might also be a pain e.g. when switching branches, if
> > > > your dir-locals.el is not checked in.
> > > As Juri mentioned, dir-locals-set-class-variables is the tool you
> > > need
> > > in those cases.  There are ample tools to solve this problem.  We should
> > > first focus on the project.el infrastructure that enables the above use
> > > case in the first place.
> >
> > 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.

Aside from the 'M--' thing, which is a compatible but separate story.