Re: Unified project interface

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

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

Why? it is what it is; it works.

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

I don't know what you mean by "learn"; the user writes the project file,
the tools read it.

Emacs uses one tool to read the project file, and extract a flat
project-search-path (the concatenation of all the Source_Path
attributes).

> In the meantime, I guess, the Ada projects will have to classify all
> dependencies together as search-path.

Yes, that's what I've been saying; it's a valid use case.

That is also what elisp is doing now.

>>  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?

Yes, but I'm not sure what. I haven't used this enough yet.

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

I know of no tool that does that; I do _not_ make that assumption. Where
did you get the idea it was meaningful?

>>> 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,

Ok

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

That's extra information, _not_ in the gem file.

> 'foo', on the other hand, resides in
> ~/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/foo-1.2.3/, 

I guess that's what ">.1.2.3" means? It's some ruby-defined library
directory in your home directory. Similar to a "system library"?

> and any edits I make to it are hard to track or push to the
> development repo.

Ok, since it's like a system library.

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

Ok.

>> So then files in project-directories are read-only, files in
>> project-search-path are read/write.
>
> Ditto.

Which is _not_ what the current code does; xref-query-replace (an edit
function) operates on the result of xref-find-regexp (among other
things), which uses (nconc project-search-path project-directories).

>> But the current default implementation of project-search-path _inludes_
>> project-directories, so this is inconsistent.
>
> Is allowed to include.

I'm not talking about the doc string; I'm talking about the actual code,
which is what elisp uses. But you've agreed to change that.

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

News to me.

If that is the intended use of these two functions, then they should be
named project-path-read-write and project-path-read-only; that will be
_much_ clearer. It can still be up to the backend to decide whether they
are flat or require additional recursion.

I've never found the need for that distinction in Ada mode.

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

Locations are tied other things besides cross-reference; cross-reference
is just one way of producing a list of locations.

find-regexp is another way.

compilation errors is another way.

All of those could use a common location API. 'project' is one place to
put it; it could be in its own 'location' namespace.

Currently, 'grep-find' and 'compilation' share the same location API.
Which is why I suggested that xref also share it. But I do like the
current xref location display, so maybe there is a case for them to
remain distinct. 

They serve different purposes; the xref display makes it easy to choose
one location from a small list; the compilation display makes it easier
to step through all of them in sequence, and it works even for very long
lists.

There should at least there should be this choice of display; the
location data structure could probably be shared (the compilation
location structure contains more info).

project-find-regexp should use the same location display API as grep-find,
since they serve very similar purposes; the user will want to step thru
all of them. Or maybe not, in some particular use case.

(grep-find could eventually be made obsolete in favor of
project-find-regexp).

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

Good.

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

That's just reimplementing Emacs grep to use the alternate location API; not
worth it.

> It's not, by itself, project-related,

Nor is it xref-related.

> and other xref backends might use it for cheap xref-find-references
> implementations.

After adding path and/or directory recursion support, for searching
project-search-path.

I hope not; better to say "xref not implemented; use Emacs grep". That will
motivate people to implement a real xref backend, as well as immediately
explaining why the xref is not accurate.


It would be nice if <menu-bar> <tools> <grep> defaulted to the
identifier at point.

-- 
-- Stephe