[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: |
Mon, 8 Jun 2015 02:15:59 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 |
On 06/05/2015 01:08 PM, Stephen Leake wrote:
No problem; make sure that directory is in project-source-directories.
How would that work, in technical terms? Which entity will "make sure"
of that? Will a project-backend "source directories" implementation
always cl-call-next-method? Will the default impl simply return the
value of some variable, assigned by a major mode?
README is a perfectly valid source file; it is written in the "plain
text" language (for which no compiler is needed ;).
I see a few problems with that:
- README has no source code (it doesn't affect the logic of any
program). "sources" already has a common meaning, and at least in one
proprietary editor it's just one a subset of all project files (see the
nomenclature here:
https://www.jetbrains.com/idea/help/content-root.html). Further, if we
can separate them, we could make sure xref-find-references only searches
in the "proper" source directories.
- There's no direct way to find the directory holding the README when
you only have the value of load-path or compilation-search-path (because
it's quite often one level above one of the path elements). 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 have no problem with projects including more than one language in the
sources; most of mine have Ada, Texinfo, LaTeX, text, elisp, and make
source code. Which is one reason why project and xref cannot be merged
(xref must be language-specific, even for tags).
xref should take the language into account, but it should work across
them as well. For instance, a Ruby method call in an *.html.erb template
file should get recognized as a reference to that method, and its "find
definition" should lead to the corresponding *.rb file.
It might make sense to parameterize project-source-directories
with a language (or major-mode) name, to get the corresponding subset.
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.
'load-path' is an elisp notion. For other languages "source-path" is
more appropriate.
I didn't mean to suggest to call anything generic a "load path".
No, xref-find-regexp should search project-source-directories.
Maybe even project-directories (project-roots?), if we agree to separate
those notions.
Most real projects include other projects, so limiting the search to
only the top project is wrong in general (although that might be a
useful option in some use cases).
Maybe when called with C-u. It's not easy to allow to specify multiple
directories that way anyway.
In addition, there might be a directory under project root that should
_not_ be searched; the object file directory for ada-mode, for example.
project-ignore-directories should be a thing. Probably in the format of
grep-find-ignored-directories (and we might have a function
corresponding to grep-find-ignored-files). Trouble is,
projectile-ignored-directories seems to be more flexible already, so
maybe that will have to be accompanied with an upgrade to how
grep-find-ignored-directories are handled.
We can make it a requirement in order to use the general tool. But first
we have to justify it; ada-mode has never needed that notion; neither
has elisp. In my experience, only config management needs it.
Like mentioned above, for example, the distinction would help with the
default xref-find-references implementation.
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.
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.
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.
ada-mode uses a plist to represent the project metadata, and has examples
of minor modes adding to the plist.
Cool. Then it must be useful indeed.
- Re: Unified project interface, (continued)
- Re: Unified project interface, Stephen Leake, 2015/06/05
- Re: Unified project interface, Dmitry Gutov, 2015/06/05
- Re: Unified project interface, Stephen Leake, 2015/06/07
- Re: Unified project interface, Dmitry Gutov, 2015/06/09
- Re: Unified project interface, Eli Zaretskii, 2015/06/09
- Re: Unified project interface, Dmitry Gutov, 2015/06/09
- Re: Unified project interface, Eli Zaretskii, 2015/06/09
- Re: Unified project interface, Dmitry Gutov, 2015/06/07
- Re: [SPAM UNSURE] Re: Unified project interface, Stephen Leake, 2015/06/07
- Re: [SPAM UNSURE] Re: Unified project interface, Dmitry Gutov, 2015/06/09
- Re: Unified project interface,
Dmitry Gutov <=
- Re: Unified project interface, Stephen Leake, 2015/06/07
- Re: Unified project interface, Dmitry Gutov, 2015/06/09
- Re: Unified project interface, Steinar Bang, 2015/06/10
Re: Unified project interface, Bozhidar Batsov, 2015/06/06
Re: Unified project interface, Eric Ludlam, 2015/06/06