Re: Unified project interface

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/04/2015 05:40 PM, Stephen Leake wrote:

> The list of directories that xref-find-regexp needs to search is not
> the project root; it is the list of directories included by the project
> source code.

Not exactly. xref-find-regexp is interested in all kinds of files, not 
just source files. That includes, say, the README file at the top of the 
project.

> For that you need a function like "project-source-directories", which
> could be customized for each project backend.

However, you raise an interesting point. Whereas xref-find-references 
would like to search in all load-path directories, maybe it would be 
enough if xref-find-regexp only searches inside the current "project 
root", for some definition of that notion.

I wonder how we could make it work this way. Make "project root" an 
orthogonal feature?

> The ada-mode project file can be anywhere; in my projects, it is usually
> _not_ at the "project root directory", but down one or two layers in
> build/ or build/release/.

We can't rely on every Elisp project declaring a "project root" in the 
same way, though.

> Hmm - vc could query for the current project root, and ada-mode would
> provide the answer. That might be useful, and a good reason to have a
> unified project interface.

VC is one option for this. Or the project may be not registered in any 
VCS yet, and the root would be determined based on, say, the presence of 
configure.ac. Again, this suggests that notions of "source directories" 
and "project root" can be somewhat orthogonal.

On the other hand, after the project root is determined, it might want 
to add some new element(s) to the source directories list.

> There are lots of project meta-data that the ada-mode project file syntax
> provides; compiler options, object directory, case exceptions, etc. Some
> of those might be common with other projects.

Right. We'll need those pieces of metadata that are useful to more than 
one subsystem, and can be employed in a general way. Though a generic 
metadata storage might be useful as well: thus, if some minor mode has 
read the project file and parsed the compiler options, it can set the 
related metadata, so that code completion and linter could use it 
without waiting for Emacs core to standardize it.

> I don't think we should try to unify the xref and project backends, but
> every major mode will probably want to provide both.

Mostly those major modes that can launch and interact with a smart 
external process, I think. The rest (except for Elisp) will leave it to 
minor modes.