Re: project.el semantics

[Stephen Leake]

John Wiegley <address@hidden> writes:

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

Me too.

> As I understand it, it has two main components:
>
>     1. Ways to determine members of a project.
>     2. Ways to usefully apply this information.

Yes.

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

My impression is Dmitry is stuck on not accepting other valid use cases
as requirements.

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

Are we still talking about emacs 25? this would be a big change from the
current API.

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

I think you've confused "Stefan" with "Stephen".

On the other hand, I don't know what part of ada-mode you are refering
to, so maybe you are talking about Stefan?

> We shouldn't even be discussing ada-mode! 

I only bring it up as an example of what a project can be used for, and
therefore what project.el should support.

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

I don't follow.

My approach is this: I should be able to rewrite the user interface of
the project-related portions of the current ada-mode on top of the
project.el API, while also adapting the current ada-mode code to provide
a project.el backend. If I can do that, then those UI functions will be
generally useful with other project backends (I can reuse them on Java
projects, etc).

This imposes requirements on the project.el API. I agree the
requirements should not be written in terms of ada-mode; ada-mode is
just one use case.

Looking at this another way; you seem to be saying "a project backend
can implement `project-roots' (or any other project function) to return
anything it wants". I don't think that works. That would mean the
project definition for `project-roots' would be:

(cl-defgeneric project-roots (project)
"Return some backend-defined information.")

How would client code, that is supposed to be backend agnostic, use this
function?

I don't understand what you mean by "define project contents however he
wants".

-- 
-- Stephe