Re: project.el semantics

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

>> In general, project.el is not about the final user interface, it is
>> about providing core functionality.
>
> Providing core functionality for third-party code that's not, usually,
> written by the user either. So it's exactly the business of project.el
> to include the kind of metadata like "these are the directories the
> user might be interested in, but the user doesn't own the code
> inside".

Ok, I can see the need for some sort of metadata. But that suggests:

(cl-defgeneric project-metadata (project dir)
"Return interesting metadata for DIR in PROJECT."
...)

We need more examples of useful metadata before we can begin to design a
format for the return result.

>> Any case where a large project is divided into subprojects, all of which
>> are editable. For example, my NASA GDS projects looked like this:
>>
>> GDS
>>      sal
>>
>>      common
>>
>>      map
>>
>>      dscovr
>>
>> All four of these are projects. "sal" and "common" are lower level; they
>> are used by "map" and "dscovr", which are the projects used by the MAP
>> and DSCOVR missions respectively (you can Google those ...). "sal" and
>
> You work on very cool projects, no question about it. :)

Used to; I'm retired now. I worked on robots before that; even more fun.

>> "common" are listed as dependencies in the "map" and "dscovr" Ada
>> project files. Nothing in "map" depends on "dscovr", and vice-versa.
>
>> So for the dscovr project, what goes in project-roots, and what goes in
>> project-library-roots, and why?
>
> Then project-roots will contain dscovr, sal and common. And
> library-roots will have what's left in the search path (Ada runtime
> library).

You did not answer the most important part of the question: "why?".

I'm left with "in order to decide which directories go in project-root
vs project-library-root, ask Dmitry".

> Personally, I expect that to be useful (e.g. limiting searches to the
> projects that you control). But if not, you an also disregard that
> distinction. Do you see any downsides to it?

Yes; it's not flexible enough. There were times when I wanted to search
only in map/, or only in sal/. I just used grep-find.

I could only dream about the other use cases I described, but they did
come up. For refactoring, I would make a low-level change, that would
generate lots of compiler errors (Ada is a big help here). Then I would
maintain a manual list of which ones were fixed in a text file.

Some more structured system would be nice.

>> Note that the Ada project tool provides only one "source search path";
>> it does not distinguish between "libraries" and "non-libraries". For the
>> dscovr project, "dscovr", "sal", "common", and the runtime library are
>> in the search path.
>
> I'm hoping that you can still distinguish sal and common from the
> standard library somehow, programmatically.

Only by knowing the directory layout of the disk; the Ada project
doesn't care, so it doesn't know.

>> xref-find-references needs similar treatment to be consistent. But I
>
> Thus far xref-find-references doesn't depend on the presence of
> "current project" (some implementations might use, some might not).
>
> So creating two variations of xref-find-references would be
> incongruous, even if maybe useful.

Right. On the other hand, a user-defined predicate would be a
reasonable feature for xref-find-references.

> If you only accept user-specified predicates, you're assuming that the
> project backend can't provide any useful information to classify the
> directories. 

The predicate can query the metadata, via project-metadata.

> I'm open to the ideas in this direction, but the UI must be better than M-:.

We have to agree that the UI is a separate discussion, or we will get nowhere.

-- 
-- Stephe