[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: |
Fri, 05 Jun 2015 05:08:49 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) |
Dmitry Gutov <address@hidden> writes:
> On 06/04/2015 05:40 PM, Stephen Leake wrote:
>
>> The list of directories that xref-find-regexp needs to search is not
>> the project root; it is the list of directories included by the project
>> source code.
>
> Not exactly. xref-find-regexp is interested in all kinds of files, not
> just source files. That includes, say, the README file at the top of
> the project.
No problem; make sure that directory is in project-source-directories.
README is a perfectly valid source file; it is written in the "plain
text" language (for which no compiler is needed ;).
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).
It might make sense to parameterize project-source-directories
with a language (or major-mode) name, to get the corresponding subset.
>> For that you need a function like "project-source-directories", which
>> could be customized for each project backend.
>
> However, you raise an interesting point. Whereas xref-find-references
> would like to search in all load-path directories,
'load-path' is an elisp notion. For other languages "source-path" is
more appropriate.
> maybe it would be enough if xref-find-regexp only searches inside the
> current "project root", for some definition of that notion.
No, xref-find-regexp should search project-source-directories.
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).
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-source-directories should return the union of the source
directories for all of the included projects. That's what load-path is
for elisp, and what compilation-search-path is for ada-mode and other
language modes.
For elisp, project-source-directories should simply return load-path.
> I wonder how we could make it work this way. Make "project root" an
> orthogonal feature?
If you mean "orthogonal to source directories", then yes, that is what I
am suggesting.
>> The ada-mode project file can be anywhere; in my projects, it is usually
>> _not_ at the "project root directory", but down one or two layers in
>> build/ or build/release/.
>
> We can't rely on every Elisp project declaring a "project root" in the
> same way, though.
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.
>> Hmm - vc could query for the current project root, and ada-mode would
>> provide the answer. That might be useful, and a good reason to have a
>> unified project interface.
>
> VC is one option for this. Or the project may be not registered in any
> VCS yet, and the root would be determined based on, say, the presence
> of configure.ac. Again, this suggests that notions of "source
> directories" and "project root" can be somewhat orthogonal.
Not just "somewhat"; "completely" :).
It also points out that "project root" is poorly defined; I think that
is because it's not at all clear when and why we need it.
> 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?
>> There are lots of project meta-data that the ada-mode project file syntax
>> provides; compiler options, object directory, case exceptions, etc. Some
>> of those might be common with other projects.
>
> Right. We'll need those pieces of metadata that are useful to more
> than one subsystem, and can be employed in a general way. Though a
> generic metadata storage might be useful as well: thus, if some minor
> mode has read the project file and parsed the compiler options, it can
> set the related metadata, so that code completion and linter could use
> it without waiting for Emacs core to standardize it.
ada-mode uses a plist to represent the project metadata, and has examples
of minor modes adding to the plist.
--
-- Stephe
- Unified project interface, Dmitry Gutov, 2015/06/04
- Re: Unified project interface, Stephen Leake, 2015/06/04
- Re: Unified project interface, Dmitry Gutov, 2015/06/04
- Re: Unified project interface,
Stephen Leake <=
- 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