Re: project.el semantics

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 11/11/2015 01:41 AM, Stephen Leake wrote:
>
>> More precisely, the only hot issue is the semantics of
>> "package-library-roots" and "package-roots".
>> ...
>> I don't understand why we have both; one would be sufficient. I have yet
>> to see an actual use case that requires both.
>
> How could I explain that better? I want to:
>
> - Search inside the project root(s). But not inside libraries.
>
> - But sometimes inside libraries as well.
>
> Because usually libraries will only bring false positives. But for
> some kinda of searches, searching in libraries proves insightful as
> well.
>
> That's missing in this description?

There is also the notion of "editable" vs "non-editable", in the doc
string for project-roots.

This doesn't tell me whether a dependency that is not a "library"
belongs in project-root or project-library-root.

But my main problem with this is that it is far too limiting.

There are many other possible use cases for restricting a search over
the list of directories related to a project:

- Search in all dependencies that come from Google (or some other
  vendor).

- Search only in directories that are not read-only.

- Search only in directories that are not marked "passed unit testing".

- Search only in directories that are not marked "refactoring for
  feature 'foo' finished".

- etc.

We cannot possibly anticipate the set of restrictions some user might
want to put on a search. So why should we assume "search on libraries"
is so important that it needs this level of attention?

I think the correct approach is to add a "predicate" argument to
functions that use the project directory path; similar to the
"predicate" argument in completion tables.

Then the user can supply a predicate function that implements each of the
above use cases. 

-- 
-- Stephe