[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: project.el semantics

From: Stephen Leake
Subject: Re: project.el semantics
Date: Wed, 11 Nov 2015 03:44:43 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

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

- 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]