Re: Unified project interface

[Dmitry Gutov]

On 08/01/2015 05:15 PM, Stephen Leake wrote:

> (cl-defgeneric project-search-path (project)
>    "..."
>    (project--prune-directories
>     (nconc (project-user-search-path project)
>            (funcall project-search-path-function)
>            ;; Include these, because we don't know any better.
>            ;; But a specialized implementation may include only some of
>            ;; the project's subdirectories, if there are no source
>            ;; files at the top level.
>            (project-directories project))))

That doesn't use recursive-search-path, and doesn't allow to treat only 
some elements recursively. Which would be natural.

And if we allowed /**, the recursive-search-path flag would be redundant.

> > (cl-defstruct (projects)
> >    flat-search-path
> >    recursive-search-path
>
> I'm guessing that here "flat-search-path" is a list of directories,
> intended to be used non-recursively.
> ...
> And then "recursive-search-path" is a list of directories, intended to
> be used recursively.

Yes.

> So they contain redundant information; they are each a cache of the
> result of the current `project-search-path' (with and without pruning).

This is backwards. There wouldn't be project-search-path function at 
all, and neither flat-search-path, nor recursive-search-path would be 
the result of pruning.

> Yes, it would be nice if we could agree that either flat or recursive is
> the baseline; any function that needs the other can convert.

That's the direction I'm inclined to take, too.

> So far, I think we have these arguments on each side:
>
> - elisp load-path is already mostly flat

For out purposes, it's plainly recursive, even if that feature isn't in 
use in most projects. That's highly unlikely to ever change.

>      it needs to be expanded to handle path/file style requires

Same as any other language with "recursive" search path that I know of.

> - Ada project paths are flat
>
>      This is actually AdaCore project paths; they support C++ and C as well.
>
> - Some other project paths are recursive

Most of them, AFAIK. I've given several examples; there have been no 
further counter-examples mentioned.

> - Converting between them (while also converting the corresponding
>    includes) is possible

I think you mean the corresponding ignores. And converting a certain 
class of ignores from recursive to flat paths seems non-trivial.

> - Using find-grep and similar external programs allows recursive search
>    to display first results immediately

That's a good point, and I think it hasn't been stated clearly before.

> > Second, like
> > I mentioned before, that loses information: in particular, we won't
> > know which directories were the root ones.
>
> If that is useful information, obviously it can be saved. That's what
> project-roots is for.

project-roots are different. This would have to be a separate accessor, 
because the search path roots outside of the project are just as (if not 
more) important.

> > I don't see why you can't write an algorithm that will
> > both handle flat directories via ignores, as well as honor the user's
> > wishes.
>
> The user has to have a way of expressing those wishes. That's what
> project-add-ignores is for.

The user will express their wishes via the project file and .gitignore.

There's nothing to discuss there; obviously, a project implementation 
will have access to all information the user will give it.

> I'll take that as agreeing to add the functions project-add-search-path
> and project-add-ignores to project.el

Not really. I don't think we should mess with a project backend's 
internals. So unless we see a use case for third-party code to modify 
project's search-path and ignores, these functions should stay out of 
the API.

> Given all of the above, I'll make an attempt to write Ada and JDEE
> project backends, using recursive paths. We'll see how that goes.

Hopefully, you'll make that attempt anyway.