Re: Unified project interface

[Dmitry Gutov]

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

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

How would that work, in technical terms? Which entity will "make sure" 
of that? Will a project-backend "source directories" implementation 
always cl-call-next-method? Will the default impl simply return the 
value of some variable, assigned by a major mode?

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

I see a few problems with that:

- README has no source code (it doesn't affect the logic of any 
program). "sources" already has a common meaning, and at least in one 
proprietary editor it's just one a subset of all project files (see the 
nomenclature here: 
https://www.jetbrains.com/idea/help/content-root.html). Further, if we 
can separate them, we could make sure xref-find-references only searches 
in the "proper" source directories.

- There's no direct way to find the directory holding the README when 
you only have the value of load-path or compilation-search-path (because 
it's quite often one level above one of the path elements). So it would 
make sense to have a different name (and a different function/slot/etc) 
for directories that might be reached that way.

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

xref should take the language into account, but it should work across 
them as well. For instance, a Ruby method call in an *.html.erb template 
file should get recognized as a reference to that method, and its "find 
definition" should lead to the corresponding *.rb file.

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

That's probably not necessary: after all, only the default 
xref-find-references implementation will use project-source-directories 
in a naive way. A smarter xref backend should determine itself which 
directories to search.

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

I didn't mean to suggest to call anything generic a "load path".

> No, xref-find-regexp should search project-source-directories.

Maybe even project-directories (project-roots?), if we agree to separate 
those notions.

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

Maybe when called with C-u. It's not easy to allow to specify multiple 
directories that way anyway.

> 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-ignore-directories should be a thing. Probably in the format of 
grep-find-ignored-directories (and we might have a function 
corresponding to grep-find-ignored-files). Trouble is, 
projectile-ignored-directories seems to be more flexible already, so 
maybe that will have to be accompanied with an upgrade to how 
grep-find-ignored-directories are handled.

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

Like mentioned above, for example, the distinction would help with the 
default xref-find-references implementation.

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

Some package that defines that root-finding logic. Not every major mode 
knows where the relevant source directories are, or it might not know 
some of them.

If we've opened one of the files in a third-party Elisp project that 
hasn't been loaded yet (so not in load-path), a project implementation 
can still add an element or several to project-source-directories, so 
that xref-find-references returns somewhat useful results anyway.

Or, say, for Ruby: while the major mode might conceivably be taught 
about paths where to find system-wide libraries, the locations of source 
files in a given project depend on the project's type, and that must be 
something a project implementation knows better. Even if it'll simply 
add the root to project-source-directories.

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

Cool. Then it must be useful indeed.