Re: Unified project interface

[Dmitry Gutov]

On 07/28/2015 06:45 PM, Stephen Leake wrote:

> 'project-roots'; return a list of related project roots.
>
> That's what renaming 'project-directories' to 'project-roots' gives us.
> Although some will object to the small name difference between
> 'project-root' and 'project-roots'.

If project-roots does not include project-root (so we limit the notion 
of "current project" to just one directory tree), it would be better to 
rename that to project-related-projects, and return project instances in 
there.

This way, the consumer can inquire about each related project's 
dependencies, as well as call project-ignores on each of them.

But that becomes more complex, because then you'd expect the consumer to 
call project-related-projects on each related project ask well, and 
traverse the whole tree, handle loops, etc.

I think it'll be better to incorporate all related projects into the 
notion of the current project, return all project roots on equal rights, 
give project-ignores an argument (one of the roots), and introduce 
project-relativize which, like described previously, will return (ROOT . 
RELATIVE-PATH).

In this scheme, project-root is not needed, because we want to treat all 
roots somewhat equally, and also because project-root shouldn't use 
default-directory, or buffer-file-name.

> Are you agreeing that the default implementation should not include
> project-root-directories?

Yes.

> The point is that if you only customize by setting
> project-search-path-function, you can't exclude project-directories.
>
> And I thought we agreed that project-search-path is disjoint from
> project-directories.

Like I said, "allowed not to include". Not matter if emacs-lisp-mode 
sets project-search-path-function, or provides a specialized 
implementation of project-search-path, it doesn't know the current 
project roots, so it can't exclude them.

> As with all such optimizations, it can only be justified by actual
> measurement.

It's an easy one, though.

> It would be less confusing if the default definition of
> project-search-path did _not_ call project--prune-directories, but
> elisp-search-path _did_.

Some caller up the stack will have to call project--prune-directories 
anyway, because we don't want to guarantee that search-path and 
project-roots don't mix (see above). However, we could provide a public 
function in project.el that will combine both. I having hard time coming 
up with the name, though: project-full-search-path doesn't sound too good.

> Then project--prune-directories should be> renamed without the '--'.

I've been waiting for a better name: there are several 
-prune-directories function in Emacs already, in different packages, all 
with different semantics.

> The doc string for project-search-path says "source directories", not
> "source root directories". That needs to be fixed.

All right. To me, the two sound equivalent, and I meant it like that.