[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: |
Tue, 28 Jul 2015 21:44:22 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 |
On 07/28/2015 07:15 PM, Stephen Leake wrote:
From an Ada project file:
Thank you.
Project_Path says where to find projects (there is also an implicit
system location); 'with "...";' says what projects to include. In this
case, "gtkada" and "gnatcoll_sqlite" are in the system location, and are
read only; sal, sal_gtk and standard_common read/write. But the Ada
project tool (as provided by the compiler vendor) makes no distinction
between "system" and "user" libraries; more precisely, it relies on the
file system read/write permissions to do that.
That's unfortunate. But you do specify "custom" locations for sal,
sal_gtk and standard_common in the beginning, right? Then a smart enough
tool could learn that information.
In the meantime, I guess, the Ada projects will have to classify all
dependencies together as search-path.
From an Android gradle file:
dependencies {
compile project(':licensesdialoglibrary')
compile files('libs/android-async-http-1.4.2-66-g4b6eb97.jar')
compile 'com.google.android.gms:play-services:+'
}
Some of these are read/write, some are read-only; gradle does not have a
mechanism to indicate that.
jars are obviously build artefacts. Doesn't the difference between
compile '...' and compile project('...') signify something, though?
Here an excerpt from an imaginary Gemfile:
gem 'foo', '~> 1.2.3'
gem 'bar', path: '../bar'
The point is that the abstract project API must handle all of these. In
the case of Ada, there is a command-line tool that parses the project
file and provides the info that Emacs needs.
I'm assuming that the build tools in other ecosystems can likewise
separate dependencies into search-path and full-on projects. Or, at
least, that most of them can, and this separation is meaningful.
And that there's no separation along different lines that's more useful
than that.
Yes, we are agreeing; some dependencies are read/write, some are read-only.
How many of each, and whether they are "system" or not, are minor
issues.
Actually, neither "system", nor "read/write" terminology strikes me as
optimal. "search path" vs. "projects" sounds better: one could edit a
file inside the system search path, with purpose, and we're should allow
that operation, but not optimize the interface for it.
In the example above, 'bar' will be one of project-directory-roots,
and 'foo' will only be in project-search-path.
Why? What effect does that have on what you can do with 'foo' vs 'bar'?
How can you tell that just from the gem file?
path: '/..' says that 'bar' is a project residing in a nearby directory,
and it's probably version-controlled. The fact that I have a Git
checkout of 'bar' is a strong indicator that I'm maintaining that
project (though not a guarantee, of course).
It makes sense to perform read/write operations on version-controlled
directories.
'foo', on the other hand, resides in
~/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/foo-1.2.3/, and any
edits I make to it are hard to track or push to the development repo.
I'm guessing you are saying "foo is maintained by the same team as the
main project (ie read/write), bar is maintained elsewhere (ie
read-only)".
The opposite of that.
So then files in project-directories are read-only, files in
project-search-path are read/write.
Ditto.
But the current default implementation of project-search-path _inludes_
project-directories, so this is inconsistent.
Is allowed to include.
And we've said that project-directories includes the main project root,
so that's also inconsistent.
Why?
So I don't understand what you are doing here.
read/write operations will use project-roots; read-only operations will
use project-roots combined with project-search-path. I though we've
already settled on that.
I don't understand; this requires deleting things from xref, not adding
to it.
xref-find-regexp uses things from xref, such as the output buffer, its
major mode, etc. They're not exposed publicly in a proper fashion, yet.
The current implementation of xref-find-regexp uses project-current,
xref-collect-matches, and xref--show-xrefs.
Right. So it uses both xref.el and project.el.
If you make the implementation of project-find-regexp use xref
facilities, then I understand your comment.
Exactly.
I was hoping for more separation.
What kind?
I suggest renaming 'xref--show-xrefs' to 'project-show-locations', and
Why project-? The procedure of displaying the locations doesn't have
much to do with the project API. The xref API, however, is very much
related.
have it take a list of locations, not implicitly call
xref-find-function.
The difficulty with that had been the necessity to track the buffers
that xref-find-function creates, in order to be able to delete each of
them that haven't been used otherwise, in xref-quit.
The parallel thread about hidden/temporary buffers should result in
solving that in a different way, and then I'll do just that.
xref-collect-matches uses grep; it can simply be moved to
project-collect-matches, along with the xref-*grep functions it uses.
The doc string needs to mention subdirs.
I think there's value in providing function, in xref, that returns a
list of matches for a given regexp in a given directory, as xref-items.
It's not, by itself, project-related, and other xref backends might use
it for cheap xref-find-references implementations.
- Re: Unified project interface, (continued)
- 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, 2015/07/28
- 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 <=
- 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
- Per-language project-search-path, was: Re: Unified project interface, Dmitry Gutov, 2015/07/31
- xref display and multiple locations, was: Re: Unified project interface, Dmitry Gutov, 2015/07/29