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: 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.



reply via email to

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