Re: Unified project interface

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.

No problem; make sure that directory is in project-source-directories.

README is a perfectly valid source file; it is written in the "plain
text" language (for which no compiler is needed ;).

I have no problem with projects including more than one language in the
sources; most of mine have Ada, Texinfo, LaTeX, text, elisp, and make
source code. Which is one reason why project and xref cannot be merged
(xref must be language-specific, even for tags).

It might make sense to parameterize project-source-directories
with a language (or major-mode) name, to get the corresponding subset.

>> 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, 

'load-path' is an elisp notion. For other languages "source-path" is
more appropriate.

> maybe it would be enough if xref-find-regexp only searches inside the
> current "project root", for some definition of that notion.

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).

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

project-source-directories should return the union of the source
directories for all of the included projects. That's what load-path is
for elisp, and what compilation-search-path is for ada-mode and other
language modes.

For elisp, project-source-directories should simply return load-path.

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

If you mean "orthogonal to source directories", then yes, that is what I
am suggesting.

>> 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.

We can make it 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.

>> 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.

Not just "somewhat"; "completely" :).

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.

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

"it" is what here ? Can you give an example?

>> 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.

ada-mode uses a plist to represent the project metadata, and has examples
of minor modes adding to the plist.

-- 
-- Stephe