[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, 29 Jul 2015 05:10:09 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 |
On 07/29/2015 04:36 AM, Stephen Leake wrote:
So you would keep project-roots, but not project-root. I can live with
that (Ada mode needs neither :).
It's fine if some projects define project-roots to nil. Unfortunately,
as I imagine it, xref-query-replace won't work for them.
Of course, we could add a preference (turned off by default) that
xref-query-replace walks the matches in the search-path, too, not just
in project-roots.
How will the elisp backend define project-roots?
It won't. Creating a project backend for Elisp seems pretty much
impossible (or rather useless), from where I'm standing.
That's why emacs-lisp-mode sets project-search-path-function instead:
the VC project backend uses it automatically.
Since it doesn't know anything about project-roots, it should either
throw an error, or return nil.
But that's exactly the problem: if I'm working on a third-party Elisp
project, it has its own repository, there's no guarantee that its root
directory is added to load-path. If all Elisp code is in the lisp
subdirectory (and it's in load-path), if I call xref-find-regexp, it
would miss all files on the level above.
On the other hand, (project-search-path (current-project)) in a .el
buffer on my machine returns:
("c:/Projects/emacs/master-build-mingw64/lisp/"
"c:/Projects/emacs/master/"
"c:/Projects/emacs_stephe.main/emacs_stephe/"
"c:/Projects/emacs_stephe.main/emacs_stephe_site_lisp/"
"c:/Projects/org.emacs.ada-mode/"
"c:/Projects/org.emacs.dvc/lisp/"
"c:/home/stephe/.emacs.d/elpa/")
Those are all 'project-roots' as far as I can tell; they each represent
a logically and physically separate collection of elisp source files
(except that master-build-mingw64/lisp/ actually has no elisp source files).
No, these are just search-path. We don't know where the roots of most of
these "projects" are.
On the other hand, "(project-directories (project-current))" returns the
single root that contains the current .el file; the same as
"(project-root (project-current))". Why does project-directories not
return a list?
It returns a one-element list.
Currently, the only code that uses project-directories is
xref-find-regexp, and it concats it with project-search-path, so it
confuses the two.
Right. Sorry, that must indeed be confusing. xref-query-replace does not
discriminate against project-search-path yet.
Ada mode has no need of project-roots. It seems elisp also has no need
of project-roots. JDE (Java Development Environment) has no need of
project-roots.
A common Java project usually has one root: the directory containing its
project file (build.xml, pom.xml, or so on).
Even so the project implementation could provide a way to open several
projects together, if explicitly told so by the user. Then it would
return them all in project-roots.
Some caller up the stack will have to call project--prune-directories
anyway, because we don't want to guarantee that search-path and
project-roots don't mix (see above).
The top-level generic API should be agnostic about that; only the
backend knows precisely what project-search-path and project-roots are.
In elisp and Ada, project-roots is simply undefined.
So?
The caller would do what xref-find-regexp does now:
(project--prune-directories
(nconc
(project-roots proj)
(project-search-path proj)))
Ada mode wants search-path to be flat, _not_ containing roots. So it
does _not_ what something to call project--prune-directories.
It wouldn't hurt anyway.
However, we could provide a
public function in project.el that will combine both.
Why?
So that the caller doesn't need to call project--prune-directories itself.
I still have not seen an actual use case for project-roots; it seems the
simplest thing is to simply drop it.
I have provided a few, along the way of this discussion.
- Re: Unified project interface, (continued)
- Re: Unified project interface, Dmitry Gutov, 2015/07/27
- Re: Unified project interface, Dmitry Gutov, 2015/07/27
- Re: Unified project interface, Stephen Leake, 2015/07/27
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface,
Dmitry Gutov <=
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/29
- Re: Unified project interface, Stephen Leake, 2015/07/30
- Re: Unified project interface, Dmitry Gutov, 2015/07/30
- Re: Unified project interface, Stephen Leake, 2015/07/31
- Re: Unified project interface, Dmitry Gutov, 2015/07/31
- Per-language project-search-path, was: Re: Unified project interface, Dmitry Gutov, 2015/07/31