Re: Unified project interface

[Dmitry Gutov]

Let's maybe continue this discussion?

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

> No, xref-find-regexp should search project-source-directories.
>
> Most real projects include other projects, so limiting the search to
> only the top project is wrong in general (although that might be a
> useful option in some use cases).

I suppose, and maybe I was wrong to suggest a distinction between 
"source" directories and the rest of them. However, here's one which 
could be better: directories to search vs. directories to modify.

Like, I might want to search the full system includes path, in a C 
project, but when performing a replacement operation (such as 
xref-query-replace), I should probably limit myself to the directories 
with code I actually own. At the moment, it's the distinction I imagine 
for project-search-path vs project-directories.

> In addition, there might be a directory under project root that should
> _not_ be searched; the object file directory for ada-mode, for example.

We have that in project-ignores now.

> We can make [root] a requirement in order to use the general tool. But first
> we have to justify it; ada-mode has never needed that notion; neither
> has elisp. In my experience, only config management needs it.
> ...
> It also points out that "project root" is poorly defined; I think that
> is because it's not at all clear when and why we need it.

Here's the first use case I know of:

There's a third-party project called rspec-mode. It allows one to switch 
between a source file and its test, and to run tests in a compilation 
buffer. For both purposes, it needs to determine the directory which to 
build the relative paths against, and in which to run the 'rspec' 
program. Currently, it does a locate-dominating-file like routine 
(looking for Gemfile or Rakefile), but it could switch to the project 
API in the future.

You're probably aware of similar tools.

So, now we have both project-root and project-directories. However, the 
relationship between them looks murky, from the consumer's standpoint. 
Like, must the former always be included in the latter?

I'm considering removing project-root, and copying a part of Atom's API 
[0]: adding a function project-relativize-path, which will, given an 
arbitrary directory, if it's inside project-directories, split its file 
name in two and return a cons, with one of project-directories in the 
car, and the relative file name against it in the cdr.

Then instead of project-root, a consumer will use (car 
(project-relativize-path default-directory)).

Thoughts?

[0] https://atom.io/docs/api/v1.0.2/Project#instance-relativizePath