Re: Subprojects in project.el

["João Távora" <joaotavora@gmail.com>]

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.

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

>>> People do seem it natural to express their custom project structures
>>> via file markers, at least that's what I see in the wild as
>>> project-find-functions customizations.
>> Yes.  Very often there are already such markers in place.  Other
>> times
>> you can add them yourself.  Other time there aren't any and the people
>> controlling the projects don't want you to add them (maybe because they
>> don't use Emacs or care about your uses).
>> But that shouldn't matter.
>> My understanding of subprojects, or the operations I want to do with
>> them isn't affected by the method by which they may be configured:
>> that's a detail that relatively easy to solve.
>
> Have you read the bug I linked to? You don't need to explain something
> I already know.

If you're already perfectly aware of it, good for you.  But this is a
public forum, I'm explaining to all the recipients of this message what
my understanding and use case is.

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

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

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

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

João