[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: project.el semantics

From: Dmitry Gutov
Subject: Re: project.el semantics
Date: Sat, 19 Sep 2015 15:40:05 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0

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


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;


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]