[Top][All Lists]

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

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Tue, 28 Jul 2015 19:25:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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


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

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

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.

reply via email to

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