[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 03:17:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0

On 09/18/2015 07:08 PM, Stephen Leake wrote:

In order to use the API correctly, the semantics of each call must be

No argument here.

That means it must be possible to tell from the API as defined by
project.el (and some future project.texi) what functions to call for
these two uses. They cannot rely on vague guesses about what some
backend might do, or what the user might want.

Yes, we need more documentation. Please simply consider the grand-parent email as bringing up an example of another use-case we might want to support.

That means project-search-path should be clearly defined to be either
purely recursive or not, so client code and project backends know
whether to weed out duplicates or not.

Let's call it "redundant", or "non-redundant". The issue seems different from the "flat" search-path we've discussed previously.

It also means the distinction between project-search-path and
project-roots must be more clearly defined.

Sure. We need more clarity WRT to redundancy in the search path, maybe better docstrings (although it's not immediately clear to me how to improve the current wording), and some good examples in the manual.

If there are use cases where different search paths are desired for
different purposes (such as "source" vs "documentation" above), the
the project API must provide a clear mechanism to distinguish those
cases, so the appropriate search path can be returned.

But what are those different purposes? So far, the distinction as I understand it is that search-path contains actual source files, and project-roots can contain anything else. So it's just source files vs any files.

The current doc strings for project-search-path and project-roots do not
make that clear, and the way they are used and implemented in current
code makes project-roots purely redundant (no code would be harmed by
simply deleting it, and some would be improved thru reduced redundancy).

The default implementations don't have enough information to do better. Would you delete the default project-search-path implementation? Then what will the VC-backend implementation of it look like?

reply via email to

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