Re: project.el semantics

[John Wiegley]

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

> Or, vice versa, some other third-party package can only expect the
> "recursive" kind of directories, and traverse them that way. That would work
> fine on most projects out there, but would lead to undesirable effects if
> someone tried to use it with the Ada backend.

I'm still not sure why this means we need to encode restrictions within
project.el, rather than, say, in Ada mode, or whichever other mode is
providing information to project.el for the traversal of its related elements.

> IME, freedom rarely implies correctness.

I want as much freedom of expression as we can get away with, so long as the
default and expected use cases remain easily within reach.

I feel, though, as if I've lost my grip on the vision for this project again.
As I understand it, it has two main components:

    1. Ways to determine members of a project.
    2. Ways to usefully apply this information.

I think our discussion so far have been in the area of #1 only, right? And is
that because we're stuck on how to define membership?

As long as, at the level of project.el, membership can optionally be a list of
"collection functions", this would allow near infinite expressiveness while
not detracting from the standard use cases of recursive and non-recursive
directory traversals.

I don't think we gain anything by "baking in" what membership means, and
disallowing flexible definitions. Such a road leads us to continuing to have
to extend and hack project.el's interface, as users run into the limits of
what it can express. Which Stefan already has done with ada-mode. We shouldn't
even be discussing ada-mode! There is a simple design path that can allow
Stefan to define his project contents however he wants. Such questions should
not even be an issue at this level of the API.

John