Re: project.el semantics

[Dmitry Gutov]

On 11/11/2015 11:44 AM, Stephen Leake wrote:

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

Not "editable". "Edited together". If that phrase looks confusing from 
the outset, please suggest a synonym.

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

Yes. I also want the user to be able to do whatever and wherever they 
want, but we must have a decent UI, too.

Maybe add the ability to tag directories with some metadata? Like vendor 
or... I don't know what else. :) The rest of your list deals with 
transient properties. They could also work if some third-party tools 
were able to modify the directory metadata.

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

Because it's easy to implement, and because that's the distinction that 
I wanted to have first. Which is like 50% of our userbase at this point.

And also because it correlates with "code ownership", which is a fairly 
common notion.