[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: Wed, 10 Jun 2015 01:31:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 06/08/2015 04:59 AM, Stephen Leake wrote:

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

Let's cut out the user out of the discussion and just say that the project system knows stuff. Because it can know everything we want to ask the user; we just need to figure out the right set of questions.

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

I don't understand this.

If project-source-directories is a generic method, maybe we can say that its implementation should almost always (unless it really knows what it's doing) call the next applicable implementation.

That implementation could be set up to dispatch based on the value of major-mode.

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

default implementation of what function?


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

Maybe there's value in allowing this semantic split to (sometimes?) go along different lines, but the two main directions I want to see commands work are these:

- Search all files that belong to any of the projects we're currently interested in.

- Search only some of those files; ones that are likely programmatically (semantically?) related to the one we're editing right now.

The latter could have a decent-enough implementation using Grep, but it would be better if we could only search directories that are related.

Maybe it's indeed an excessive requirement, though. After all, backends can provide their own implementations of "find references" already.

and at least in one proprietary editor it's just one a subset of all
project files (see the nomenclature here:

That gives me 404

That link still works for me. Maybe your email client mangles it somehow?

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

I intend to allow the user to specify the exact directory for xref-find-regexp to search, when called with a prefix. However, allowing to input an arbitrary set of directories is obviously non-trivial (if we want to have an interface that's not annoying).

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?

I mentioned compilation-search-path only as an example, though I didn't expect that you might suggest putting the project root into compilation-search-path.

Anyway, emacs-lisp-mode doesn't set compilation-search-path. And hopefully you're not suggesting to put project roots into load-path, just to be able to search READMEs.

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?

If my java project is in ~/vc/fooberz, then project-directories would be '("~/vc/fooberz"), and project-source-directories would be '("~/vc/fooberz/src"). That seems obvious enough, so maybe I don't understand the question.

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.

It's targentially related, but the difficulties in displaying and editing multi-mode files are entirely different from the subject of this discussion.

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.

Maybe, or maybe not; but that's not very relevant. If the tool *can* be written, the API is manageable. In the meantime, we can use Grep.

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.

I suppose all parts of the "hierarchical project" will employ the same project definition logic, possibly enabled by the same minor mode. And that minor mode might as well implement the specialized xref backend that will know where to search.

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

See the beginning of this email.

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.

Or you're missing mine.

The distinction I'm (or was) suggesting is not between the root and everything else, but between "source directories" and "other directories the user might want to search in", and we'll often want to see the project's root directory inside the latter list (when not in both).

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.

Allow me to repeat: "it" is the package that defines the root-finding logic. Defines the logic that determines the bounds of the current (and possibly linked) project(s).

The act of find the project root directory may sometimes be skipped in some odd cases, but otherwise, it'll usually be the first step to determining the current project.

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

So there'll be several roots. Or project-directories. No big deal.

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 root directory usually, a) contains data about the project structure, b) includes files we want to search.

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

First of all, those forms specify path relative to *any* load-path element. We can't add every permutation. Second, I was describing the case where the requires load-path element weren't even set yet.

Third, either way it won't include the files that depend on the current one. Those are important, too.

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

It's some parent directory of the currently opened file. Probably not the direct parent. It's important because it contains files related to the current one.

> Why is that a "root" as opposed to just some source directory?

That's a weird question. It's a root of the project. It *is* also one of the source directories, in this example.

reply via email to

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