Re: Unified project interface

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

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

The user; they are the only ones that know what "the project" is.

> Will a project-backend "source directories" implementation
> always cl-call-next-method? 

I don't understand this.

> Will the default impl simply return the value of some variable,
> assigned by a major mode?

default implementation of what function?

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

It's the other way around; there is no object code corresponding to the
README source code.  But that's not very significant.

> "sources" already has a common meaning, 

What is that? I take it to mean "any human-readable file". Which thus
includes README, Makefile, .git/config, etc.

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

That gives me 404

> Further, if we can separate them, we could make sure
> xref-find-references only searches in the "proper" source directories.

What do you mean by "proper"?

We need it to search what the user wants to search; the user needs to be
able to specify that clearly and easily.

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

If the user specifies compilation-search-path (directly or indirectly),
and the user wants to be able to search README, then the user must
include the directory containing README in compilation-search-path.

Is that a problem?

> 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 don't follow; can you give more details, and a clear example?

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

Ah. Now you are talking about one file that mixes source in two
languages. Yes, that is a problem. There have been discussions here of
multi-mode files. I don't know how that would work in practice.

I have projects that mix Ada and C++; the project level cross reference
facility handles both, using the current xref API. That works because
gcc generates the same cross reference info for those two langauages; I
doubt there is something similar for Ruby and html.

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

I don't see how that is at all possible, especially in the face of
hierarchical projects.

Only the user knows what a "project" is; they write the hierachical
project files that tell the system what the project structure is.

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

You seem to be missing my point; I see no need for project-root, outside
of configuration management. So I don't see why xref should care about
"root" at all.

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

As I've said, none of the languages I deal with care about a "root"
directory. Only git, mtn, cvs care.

Hmm. Java imposes something like a root by forcing the directory
structure to match the hiearchical package naming. But referencing other
package hierarchies complicates that, just as in Ada and C++.

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

What does that have to do with "root"?

The third-party elisp file will presumably have some paths in "(require
...)" forms that will define a set of directories to be added to
project-source-directories. 

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

What "root"? Is that the directory containing the Ruby file that we
opened? Why is that a "root" as opposed to just some source directory?

-- 
-- Stephe