emacs-devel
[Top][All Lists]
Advanced

[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: Fri, 5 Jun 2015 03:08:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

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, maybe it would be enough if xref-find-regexp only searches inside the current "project root", for some definition of that notion.

I wonder how we could make it work this way. Make "project root" an orthogonal feature?

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.

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.

On the other hand, after the project root is determined, it might want to add some new element(s) to the source directories list.

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.

I don't think we should try to unify the xref and project backends, but
every major mode will probably want to provide both.

Mostly those major modes that can launch and interact with a smart external process, I think. The rest (except for Elisp) will leave it to minor modes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]