[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unified project interface
From: |
Stephen Leake |
Subject: |
Re: Unified project interface |
Date: |
Tue, 28 Jul 2015 20:36:25 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
Dmitry Gutov <address@hidden> writes:
> On 07/28/2015 06:45 PM, Stephen Leake wrote:
>
> I think it'll be better to incorporate all related projects into the
> notion of the current project, return all project roots on equal
> rights,
That is certainly what Ada mode does, and gradle.
> give project-ignores an argument (one of the roots), and
> introduce project-relativize which, like described previously, will
> return (ROOT . RELATIVE-PATH).
>
> In this scheme, project-root is not needed, because we want to treat
> all roots somewhat equally, and also because project-root shouldn't
> use default-directory, or buffer-file-name.
So you would keep project-roots, but not project-root. I can live with
that (Ada mode needs neither :).
> Not matter if emacs-lisp-mode
> sets project-search-path-function, or provides a specialized
> implementation of project-search-path, it doesn't know the current
> project roots, so it can't exclude them.
How will the elisp backend define project-roots?
Since it doesn't know anything about project-roots, it should either
throw an error, or return nil.
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).
So for elisp, it seems we are definining project-search-path to be
project-roots.
Which goes a long way to explaining why this has been so confusing.
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?
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.
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.
>> It would be less confusing if the default definition of
>> project-search-path did _not_ call project--prune-directories, but
>> elisp-search-path _did_.
>
> 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.
Ada mode wants search-path to be flat, _not_ containing roots. So it
does _not_ what something to call project--prune-directories.
> However, we could provide a
> public function in project.el that will combine both.
Why?
I still have not seen an actual use case for project-roots; it seems the
simplest thing is to simply drop it.
>> The doc string for project-search-path says "source directories", not
>> "source root directories". That needs to be fixed.
>
> All right. To me, the two sound equivalent, and I meant it like that.
The difference is whether recursion into subdirectories is required (in
this case, allowed); that is always worth documenting; it is normally an
option in search functions (think grep vs grep-find;
semantic-symref-find-references-by-name has a :scope argument).
--
-- Stephe
- 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 <=
- Re: Unified project interface, Dmitry Gutov, 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, 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