Re: project.el semantics

[Dmitry Gutov <dgutov@yandex.ru>]

On 09/19/2015 03:07 PM, Stephen Leake wrote:

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

Let's call it "non-redundant".

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

Yes.

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

Sure, EDE has no quirks at all.

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

Why do you think "failure to go to an include file" would be among those 
quirks?

Rather, I would imagine that if #include didn't allow files in 
subdirectories, the main problem with the find-file-in-includes function 
that was implemented as if it did, would be that it would allow to go to 
*too* many files, not too few. So, false positives, not false negatives.

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

Hence the word "think". But how would it help? Redundant or not, 
C_INCLUDE_PATH is "recursive" like I've described in the previous 
message. How would a "project-flat-search-path" relate to it?

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

On the one hand, project-search-path being non-redundant would be more 
useful for the currently implemented commands, as well as 
find-file-in-project.

One the other hand, if we add a second generic in the future, 
project-search-path seems like a better name for the *redundant* one of 
the two. Don't you think?

But changing this generic's semantics later might not be an option anymore.

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

That's how I read that paragraph: "Sure, naturally, yeah... waaait a 
minute!"

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

...OK?

> I'm glad you agree. So why do you refuse to fix the
> documentation to be clear?

Because if we "fix" it that way now, we might decide that the matter is 
closed. Whereas a proper fix shouldn't be too hard, and with 
find-file-in-project implemented, find-file-in-includes would be just 
one step away.

> savannah Emacs git.

Fair enough. Somewhere in etc/?