Re: Unified project interface

[Dmitry Gutov]

On 07/26/2015 09:57 PM, Stephen Leake wrote:

> Then it's not "global", is it? It's "operate on this set of projects,
> exclude that set". So you need a way to specify sets of projects.

Maybe the "global" is not the right word, but I'm quite confident that 
if I ask an average user what a "search across project" action should 
do, it would replace in the current project, (maybe) in the included 
ones, and definitely not in the installed libraries. Even if they're 
writable.

Even if we add a "choose which projects to touch" interface, it's good 
to have a reasonable default.

> > But according to you, the "search path" will be just the directories
> > inside the project's tree, right?
>
> No, I have been explicitly saying that is not the case; the search path
> is whatever the project file says it is.

Sorry, I've replied to that part before reading the rest, and then 
forgot about it.

> A list of project names. Depending on the project manager, that implies
> a list of project files in one syntax or another, each of which
> specifies a set of project directories (explicitly or implicitly).

Could you give an example?

Since they're referred only by names, this sounds like a list of 
dependencies on the installed packages. Those we usually don't want to 
edit, and I'd classify them as system includes.

> Trust what the project file says. The user told Emacs to use the project
> file; it should not try to be smarter.

So, xref-find-regexp won't call project-root. Got it.

> If the user wants documentation in the project, then it is in the
> project file. If the project manager tool is brain-dead and can't handle
> documentation, the the user can switch tools.

In that case, will the user add the documentation directory to the 
search-path section of the project file?

> No. We should have project-root for tools that need a root directory.
> xref-find-regexp needs a search path, not a root directory.

It could include the root directory in the search path, if it's not 
already there. But it seems you don't want to do that. Okay.

> xref-find-regexp searches project-search-path. project-search-path is
> set by reading the project files. The project files are provided by the
> user. Voila, xref-find-regexp does _exactly_ what the user wants, no
> more, no less.

Very well.

To sum up, I see a strong case for project-search-path as you described 
it (maybe under a different name; like project-directories, as it is 
now), and so far, no real case for project-root.

Further, the system search path should be separate, because it's usually 
specified like that in project files already, in my experience.

And if someone were to create, say, an ECB panel showing the current 
project layout, they might appreciate having the information about these 
directories being different.

If you (or someone else) don't like using "project search path" for the 
system libraries path, feel free to suggest another name.