Re: project.el semantics

[John Wiegley]

>>>>> Dmitry Gutov <address@hidden> writes:

> It's supposed to be a generic replacement for the top-level EDE ede-project
> class, more or less.

Except I don't know what that is. :(

> Those are outside. Does "external to the project" sound better?

Ah, I think so, yes. "Ancillary roots" might be even better.

> Since you both don't understand the few sentences that seem clear to me, I'm
> apparently an utter failure of a technical writer. Which is not terribly
> surprising, considering it's my second language.

I don't mean to criticize your writing. It's hard to speak at the level of
precise specification.

> Not "within the project", but related to the project. Does the term
> "library" sound familiar?

OK, this is starting to make more sense now. So, you're saying that *within* a
project there are both distinguished directories, and file subsets with common
meaning; and *outside* the project (say, in "/usr/include"), that are likewise
distinguished directories and file subsets with common meaning.

What we may want to do is avoid the concept "root" entirely, and talk instead
about general "filesets": That is, every "project" would have 0 or more
associated filesets, and a way to identify which project (perhaps multiple!)
that a given buffer is associated with.

A fileset could be defined as:

    Everything within a directory
    Everything within a directory tree
    Everything within a directory or tree matching a predicate

In the most general case, a fileset is determined by whatever function the
user provides in .dir-locals.el.

Filesets in turn have an extensible set of attributes:

    Is the file part of the project, or external to it?
    Is it under version control?
    Is it a build product?
    Should it be searched, tagged, presented in various contexts, etc.?
      (This itself might be an extensible sublist)

This way we can talk in general terms, and not about concrete roots or
directories. In the most abstract case, the notion of "project" should be
entirely definable by the user, and may look nothing like what we presently
have in mind. It's even possible that a buffer without an associated file, say
a *Compilation* buffer, could momentarily be considered part of a project, and
as a candidate for cross-buffer searching within that project.

John