Re: project.el semantics

[Dmitry Gutov <dgutov@yandex.ru>]

On 11/11/2015 12:27 PM, Stephen Leake wrote:

> My point is you don't have a good use case for "library", either. At
> least, the use case for "search only on libraries" is no more important
> than other similar "search only on ..." use cases.

You can't say I don't have a use case when I do use it. Just take it on 
faith.

"search only on libraries" doesn't seems particularly important, but 
"search in project only" and "in project + libraries" are.

>> How would they provide the predicate when calling the command
>> interactively? Especially a predicate that would distinguish between
>> project roots and library roots.
>
> In a lot of cases, they will simply search the entire directory list,
> and filter the results manually as they go thru them.

That's not an answer to the question.

> But they can take the time to write a predicate function, and invoke the
> command via M-; to supply it as an argument in the call.

That's not how we usually imagine a user interface.

> Or they could write a wrapper that provides a list of common predicates.

A user, conceivably, could. Because they probably know the layout of a 
given project; even though they might have to create a new wrapper for 
each project, or a kind of project, they work on.

But third-party code that might use project.el, doesn't know anything 
about the project, except what project.el tells it.

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

> Since project-roots is treated recursively, "not included in" means (not
> (file-in-directory-p ...)) to me.

Not to me. We need a third opinion here. I might be biased, of course:

http://apidock.com/ruby/v1_9_3_392/Enumerable/include%3F

>> And "not member" semantics seems pointless to me here; we might as
>> well allow project-library-roots to include project-roots element, if
>> the consumer will have to call `project-combine-directories' on them
>> together.
>
> I'm confused. With the current definitions, project-roots and
> project-library-roots are disjoint, so the user does have to call
> project-combine-directories if they want to search on both.

Why are you confused? Look at the definitions: they use `append'.

> You now seem to be agreeing with me; it would be better to have only
> one project-roots function.

Nope.

>> Having "library roots" entirely outside the project roots, however,
>> makes a lot of sense to me intuitively: if they're inside, they are a
>> part of the project anyway. What kind of use would we have for such
>> elements?
>
> I'm not sure what you are asking here.

I was continuing the line of thought that started with the assumption 
that you want the (not (member ...)) semantics.

> You seem to be asking "why would we want to search on
> project-library-roots".

No.

>> Would you be able to give an example of a project file that lists
>> dependencies like that, that "should be edited together" with the
>> current project? It would fit the manual well.
>
> We have not defined an Emacs project file yet. I can easily provide an
> Ada example, but I don't think you want that actual file in the Emacs
> manual.

Not the contents of the file, of course. I just want to construct a 
realistic-sounding sentence, maybe mentioning Maven modules or whatever.

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

(And MAP is apparently WMAP).

> "common" are listed as dependencies in the "map" and "dscovr" Ada
> project files. Nothing in "map" depends on "dscovr", and vice-versa.

There is a choice here, would you always use the same project 
instance/configuration when working on any of them (option 1, see 
below), or would you use different project instances when working on map 
and dscovr (option 2).

> ...
 > Any GDS team member can edit any
> file in any project.

I'm going to assume that they not only can, but also do that, with some 
regularity.

> The only thing that is a "library" is the Ada runtime library, installed
> with the Ada compiler.

That's fine. In the general case, though, you could have some 
third-party libraries installed as well, right?

> So for the dscovr project, what goes in project-roots, and what goes in
> project-library-roots, and why?

Apparently you're going with option 2.

Then project-roots will contain dscovr, sal and common. And 
library-roots will have what's left in the search path (Ada runtime 
library).

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?

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

>>> I could write a new global xref backend, but it's better to reuse
>>> existing code.
>>
>> Does lisp/cedet/cedet-global.el have code that will help us with
>> implementing "find definitions" using Global?
>
> Yes. I've started an implementation that does that:

That's great. I've also been thinking of the "tag by name" 
implementation for Grep, to use as a slow fallback. So far, it involves 
piggybacking on font-lock.

>> We have both project-find-regexp and project-or-libraries-find-regexp
>> already, and I find the difference between them useful in practice.
>
> Yes, sorry, I temporarily forgot about those; they are new.
>
> 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.

> think that's the wrong approach; adding a more general user-specified
> predicate function is much better.

If you only accept user-specified predicates, you're assuming that the 
project backend can't provide any useful information to classify the 
directories. Whereas I think it pretty handy if the user doesn't have to 
write any code to start taking advantage of some basic distinctions 
(like "project contents" vs "libraries").

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