[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Mon, 8 Jun 2015 02:15:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]