From: Dmitry Gutov <dgutov@yandex.ru>
To: Stephen Leake <stephen_leake@stephe-leake.org>, emacs-devel@gnu.org
Subject: Re: Unified project interface
Date: Wed, 29 Jul 2015 05:10:09 +0300 [thread overview]
Message-ID: <55B83601.9060706@yandex.ru> (raw)
In-Reply-To: <86si87923q.fsf@stephe-leake.org>
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.
next prev parent reply other threads:[~2015-07-29 2:10 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 11:43 Unified project interface Dmitry Gutov
2015-06-04 14:40 ` Stephen Leake
2015-06-05 0:08 ` Dmitry Gutov
2015-06-05 10:08 ` Stephen Leake
2015-06-05 13:03 ` Stephen Leake
2015-06-05 13:14 ` Dmitry Gutov
2015-06-08 1:24 ` Stephen Leake
2015-06-09 18:16 ` Dmitry Gutov
2015-06-09 18:21 ` Eli Zaretskii
2015-06-09 18:49 ` Dmitry Gutov
2015-06-09 19:03 ` Eli Zaretskii
2015-06-07 23:22 ` Dmitry Gutov
2015-06-08 1:35 ` [SPAM UNSURE] " Stephen Leake
2015-06-09 19:04 ` Dmitry Gutov
2015-06-07 23:15 ` Dmitry Gutov
2015-06-08 1:59 ` Stephen Leake
2015-06-09 22:31 ` Dmitry Gutov
2015-06-10 7:13 ` Steinar Bang
2015-07-08 0:25 ` Dmitry Gutov
2015-07-11 13:43 ` Bozhidar Batsov
2015-07-11 14:17 ` Dmitry Gutov
2015-07-12 14:42 ` Dmitry Gutov
2015-07-13 8:49 ` Bozhidar Batsov
2015-07-13 10:23 ` Dmitry Gutov
2015-07-24 23:43 ` Dmitry Gutov
2015-07-25 0:55 ` Stephen Leake
2015-07-25 7:29 ` Eli Zaretskii
2015-07-26 2:12 ` Dmitry Gutov
2015-07-26 2:45 ` Eli Zaretskii
2015-07-26 11:25 ` Stephen Leake
2015-07-26 2:11 ` Dmitry Gutov
2015-07-26 11:22 ` Stephen Leake
2015-07-26 17:23 ` Dmitry Gutov
2015-07-26 18:57 ` Stephen Leake
2015-07-26 23:56 ` John Yates
2015-07-27 1:49 ` Dmitry Gutov
2015-07-27 11:12 ` Stephen Leake
2015-07-27 11:27 ` Dmitry Gutov
2015-07-27 13:00 ` Dmitry Gutov
2015-07-27 13:02 ` Dmitry Gutov
2015-07-28 1:21 ` Stephen Leake
2015-07-28 11:05 ` Stephen Leake
2015-07-28 14:33 ` Dmitry Gutov
2015-07-28 15:45 ` Stephen Leake
2015-07-28 16:25 ` Dmitry Gutov
2015-07-29 1:36 ` Stephen Leake
2015-07-29 2:10 ` Dmitry Gutov [this message]
2015-07-28 14:18 ` Dmitry Gutov
2015-07-28 16:15 ` Stephen Leake
2015-07-28 18:44 ` Dmitry Gutov
2015-07-29 2:27 ` Stephen Leake
2015-07-29 22:51 ` Dmitry Gutov
2015-07-30 8:17 ` Stephen Leake
2015-07-31 0:15 ` Dmitry Gutov
2015-07-31 16:13 ` Stephen Leake
2015-08-01 0:57 ` Dmitry Gutov
2015-08-01 9:50 ` Stephen Leake
2015-08-01 10:51 ` Stephen Leake
2015-08-01 12:42 ` Dmitry Gutov
2015-08-01 12:40 ` Dmitry Gutov
2015-08-01 14:15 ` Stephen Leake
2015-08-01 15:09 ` Dmitry Gutov
2015-08-01 19:04 ` Stephen Leake
2015-08-01 22:33 ` Dmitry Gutov
2015-08-01 1:14 ` Per-language project-search-path, was: " Dmitry Gutov
2015-08-01 10:43 ` Stephen Leake
2015-08-01 14:12 ` Dmitry Gutov
2015-08-01 18:57 ` Stephen Leake
2015-08-02 0:25 ` Dmitry Gutov
2015-08-02 2:29 ` Eric Ludlam
2015-08-02 8:57 ` Nix
2015-08-02 17:14 ` Michael Heerdegen
2015-08-02 23:09 ` Eric Ludlam
2015-08-02 23:39 ` Michael Heerdegen
2015-08-03 11:33 ` Eric Ludlam
2015-08-02 23:07 ` Dmitry Gutov
2015-08-03 10:24 ` Nix
2015-08-03 10:35 ` Dmitry Gutov
2015-08-07 15:25 ` Nix
2015-08-03 1:21 ` Dmitry Gutov
2015-07-29 23:11 ` xref display and multiple locations, " Dmitry Gutov
2015-06-06 10:20 ` Bozhidar Batsov
2015-06-06 10:29 ` Dmitry Gutov
2015-06-06 12:32 ` Eric Ludlam
2015-06-06 18:44 ` Dmitry Gutov
2015-06-06 19:28 ` Eli Zaretskii
2015-06-07 22:29 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B83601.9060706@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=stephen_leake@stephe-leake.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.