Re: project.el semantics

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/18/2015 08:14 PM, Stephen Leake wrote:
>
>> However, if the C include path is not purely recursive (which is
>> likely),
>
> What is this guessing? I'm pretty sure it *is* "purely recursive", and
> if not, please quote some documentation.

"purely recursive" means no element of the path is a subdirectory of
another element.

It is quite possible for a project to have an include path like
"root/include/dir1 root/include/dir1/dir2".

>> then a purely recursive project-search-path will not be a
>> superset, and this will fail (so it will fail with all of the current
>> implementations of project-search-path).
>
> I'm pretty sure that even if that were the case, it could be a
> good-enough feature, just one with undesirable quirks.

Not a good advertisement for the project API. If I saw that statement in
the project user guide, I'd stop reading, and go learn about EDE.

Failure to go to an include file would certainly be "undesireable". I
don't think "quirk" is the right term, though; "bug" and "bad design"
are more appropriate.

>> That's an argument for providing project-flat-search-path (overkill for
>> this use case, but not harmfull),
>
> I don't think it is. 

Interesting. First you admit that your approach is wrong, then you deny
that another approach would work, without any proof.

> Please, let's cease the flat-search-path
> discussion until we encounter a use case that's *really* hard to
> handle without it.

We already have, at least twice. But you refuse to listen, so yes, I'll
stop trying.

> I admit
> returning redundant elements is not documented, but for now it's just
> an idea, not something set in stone. Eventually it'll need to be
> documented, whichever way the decision comes out.

What's wrong with picking one now, and documenting that? That at least
gives us a better defined base to start from.

>> But the API is the interface between the clients and the backend; it
>> would be much better to have clearer semantics, and options in the API
>> to choose among the possible semantics. That way client code can be
>> written that is truly independent of the project backends, and new
>> backends won't break existing client code.
>
> 100% agreement, except for "options in the API to choose among the
> different semantics". It's better to only have to deal with one
> semantics, as long as the result can be just as powerful.

Interesting; how to say "yes" and "no" in the same paragraph.

>> On the other hand, if we define project-search-path to return
>> mixed-recursive (to match load-path or C include exactly), some client
>> functions may be able to use it as is (they will have to make
>> assumptions about what the backend is including).
>
> The statement in parens above seems like a recipe for disaster. How
> would a function know what the backend is including? Will it have to
> provide different implementations for different backends? Remember,
> we're striving for "backend-agnostic" here.

Precisely my point; I'm glad you agree. So why do you refuse to fix the
documentation to be clear?

>> We should start a file that documents the use cases we've discussed, so
>> we don't forget them.
>
> Any suggestions for the collaboration platform?

savannah Emacs git.

-- 
-- Stephe