[Top][All Lists]

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

Re: project.el semantics

From: Dmitry Gutov
Subject: Re: project.el semantics
Date: Wed, 11 Nov 2015 15:39:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

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

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

reply via email to

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