Re: project.el semantics

[Dmitry Gutov]

On 11/11/2015 11:55 AM, Stephen Leake wrote:
> Dmitry Gutov <address@hidden> writes:
>
> > project vs libraries. Or, "files we own and edit" vs "files we
> > sometimes want to look at" (and maybe edit during debugging).
>
> Those are conflicting criteria, so you are proving my point.

I don't see that.

> As an example, you define project-library-roots for elisp to include
> _all_ of load-path (see the recently added function
> `elisp-library-roots').
>
> On a user machine (not a developer machine), a lot of load-path is
> treated as read-only. But some is not. So why is it in
> project-library-roots?

a) They might be editable (and even authored by the user), but it's 
pretty likely that they are not the part of the current project. Which 
can be Emacs (which doesn't depend on any load-path directories outside 
of its tree; it just helps them work).

b) We have no project files to determine the actual dependencies of the 
little Elisp package you're working on, and figure out which projects 
it's tightly coupled to.

> The obvious answer is "because there is no way to tell which
> subset of load-path is treated as user-editable".
>
> Note that "owned by the user" is not enough; ELPA packages are not editable,
> but they are in ~/.emacs.d/elpa, owned by the user. And a user may have
> installed Emacs in their own directory tree.

"editable" and "owned by the user" is irrelevant. The docstring doesn't 
mention either of those conditions.

> Which is precisely my point; there is no good way to decide whether a
> directory belongs in project-roots or project-library-roots.

Not if you only take one word from the whole docstring. It says 
"directory ... contents meant to be edited together".

Which, yes, if impossible to determine for load-path, which is why it 
goes into library-roots.

But it's possible to answer that question in other languages and 
configurations.