[Top][All Lists]

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

Re: project.el semantics

From: Dmitry Gutov
Subject: Re: project.el semantics
Date: Sun, 8 Nov 2015 15:07:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

On 11/08/2015 09:11 AM, Stephen Leake wrote:

These are inconsistent.

It would be best for the project-library-roots-function doc string to
_only_ refer to cl-defgeneric (ie, "default implementation of
`project-libary-roots'"), so you don't have duplicate documentation that
gets out of sync.

It would be impossible for project-library-roots-function to implement the "outside of the current project" part of semantics, unless we pass it the current project.

And then, what's the point? It's just as easy to call project-subtract-directories from the default project-library-roots impl.

Any other inconsistencies? (I've pushed a minor update now, but it's probably unrelated to your concerns).

You seem to be trying to establish a difference between "a single
project" and "the libraries used by a project". Better terminology would
be "top level project" and "dependencies"; not all dependencies are
libraries. It would be helpful to make this distinction more explicit.

I think we might want to introduce the notion of project dependencies later, and then we'd have to call some of library-roots, again, library roots, to distinguish from the dependencies.

Better to defer that change.

Note that you currently have the freedom to include the checked out dependent projects in the project-roots (if you edit these projects together).

The default implementation of project-library-roots makes the lists
disjoint, so the doc strings should say that.

Doesn't it? It says "outside".

In particular,
"load path" and "class path" contain _both_ the top level project and
the dependencies, so project-library-roots should _not_ be the same as
"load path" or "class path".

I think "list of directories outside of the project" is pretty clear.

The advice in project-roots on "include here but not there" should
mention top-level vs dependencies.

Could you rephrase that? I'm not sure I follow.

On the other hand, `project-library-roots ((project (head vc))' does
_not_ make them disjoint, so there is a bug here somewhere.

Fixed, thanks for pointing that out.

The new function `project-find-regexp' is not consistent with other
usage; other project- search functions search both top level and

Sorry, what other project- search functions? Do you mean xref-find-references?

Note that we also have project-or-libraries-find-regexp. IME, when doing a regexp search across the project, you aren't interested in the library code, most of the time.

Also see the FIXME commentary above project-library-roots-function;
it's waiting for the public opinion. Though it's not really about
source vs documentation as much as about different kinds of sources.

That FIXME: says, in part:

;; FIXME: Using the current approach, we don't have access to the
;; "library roots" of language A from buffers of language B, which
;; seems desirable in multi-language projects, at least for some
;; potential uses, like "jump to a file in project or library".

emacs-lisp-mode makes project-library-roots-function buffer-local,
which makes it language-specific. That's an argument for overriding the
default implementation of project-library-roots to do something more
useful. Which is what `project-library-roots ((project (head vc))' does,
for example. Which means that the behavior of projects in an elisp file
that happens to be in a vc directory is different from one that is not.

`project-library-roots ((project (head vc))' knows nothing of library roots, however, aside from the local variable that's supposed to be set by the user.

No other language mode sets project-library-roots-function.

There is etags-library-roots, however. It's not language-specific, but, again, vc-project doesn't know about it.

There is also ruby-library-roots already brewing in my head.

The root cause of this problem is trying to infer a project in an elisp
file. This makes sense in general, because an elisp file implies the use
of load-path, which is the main part of defining a project. A better way
is to provide a project-find-function that returns an elisp-project
object in elisp buffers;

That implies having to create a separate project implementation for every language, making vc-project utterly useless.

You'd also have to create yet-another kind of project implementations, for multi-language projects.

Note that determining whether the a given directory tree has Elisp files inside is not 100% reliable, outside of traversing it whole. But if we pick some detection mechanism, (and we'd have to, for Elisp-project detection), we can just as well use it to call elisp-library-roots globally and make it auto-detect whether the current project is applicable. Like described in the FIXME.

then elisp-project can override
project-library-roots to return load-path; it could also add the emacs C
sources if they are available.

At the moment, I feel that this approach would be a cop-out. But it's definitely an option.

That leaves the default behavior in non-elisp files that are also not in
a vc directory; they currently use 'etags-library-roots. You could
change the default definition of project-library-roots to use
etags-library-roots directly, but it seems better to have a variable for

I don't think we ever call project-library-roots-function from anywhere but project-library-roots (*). And that requires the presence of the current project.

I would delete the advice that overriding functions should use
project-library-roots-function; the main reason to override is to do
something different.

(*) Hence, if we go your way, there seems to be no need for project-library-roots-function.

I have no problems merging this branch to master; it makes things better
in most places, and no worse in any. Howver, it would be best to clean
up the inconsistencies above first.

Thanks, I'll merge after your next reply.

reply via email to

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