Re: Unified project interface

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/29/2015 05:27 AM, Stephen Leake wrote:

> Why? it is what it is; it works.

It gives us less information than it could, about the project configuration.

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

Figure out somehow, based on the project file and the contents of the 
file system, hopefully without asking the user more questions.

For instance, even if the project file gives no direct indication of 
which search-path elements are "proper" projects, some Elisp code could 
look inside each of those directories (and one level above, maybe) and 
see if there are project files in any of them. And those where there 
are, promote to project-roots as well.

That might be harder for Ada, but should be totally doable for 
Java-based projects (if build.gradle doesn't provide that info).

> Yes, that's what I've been saying; it's a valid use case.
>
> That is also what elisp is doing now.

Elisp is also relying on runtime information. It's not reliable enough, 
IMO, to use as the basis of xref-query-replace, for instance. Like I 
mentioned in the other email, the project I've opened right now isn't 
necessarily in load-path.

AdaCore and Gradle are in better positions than 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.

That might be worth investigating.

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

The IDEs usually separate the "current project" (one root with its 
subtree) from the system dependencies. Especially in the Java world, 
where there's just too much code to look at.

Multi-project builds also exist, but they seem to be usually constrained 
to the "several projects inside one parent directory" configuration, see 
"7.3. Multi-project Java build" in 
https://docs.gradle.org/current/userguide/tutorial_java_projects.html.

Also, here's a screenshot of a "project drawer" in a popular IDE: 
http://blog.pivotal.io/wp-content/uploads/2012/02/intellij_modules.png

It showcases a separation of the current project's "modules" from 
"external libraries".

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

It's a good assumption. Even if it's not version controlled, it's most 
likely a working directory anyway, and the developer's just being 
ignorant about version control.

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

Exactly like a system library.

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

Indeed. But that shouldn't be surprising: we are discussing a change 
proposal, and xref-find-regexp, xref-query-replace, and other related 
code you can see in master, had all been written before the current 
iteration of this thread.

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

Ah, yes, of course. I intend to change that.

But consider this: elisp-search-path is not ideal (the current project 
could be not in load-path). So if project-search-path only consults 
project-search-path-function, by default, what will the default 
implementation of xref-find-references use?

Just (project-search-path (project-current)), or

  (project-prune-directories
    (append
      (project-roots proj)
      (project-search-path proj)))

?

The latter moves the same logic into the caller. The former will give 
the user false negatives, in the absence of a smart, language-aware 
project implementation.

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

Err, that sounds silly. Why would you want not to recurse?

The current xref-collect-matches implementation unconditionally 
recurses, and it doesn't seem particularly useful to create a variant 
that doesn't.

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

I suppose you're right. But until we have a unified location API (which 
I wouldn't count on appearing anytime soon), xref is the better place.

xref-location lives there, and it's the best purpose-agnostic location 
class that we have now.

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

But there's not much API there, is there? To obtain the list of matches 
from the Grep or Compilation output, one has to re-search-forward in 
that buffer.

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

I think it's useful enough.

>> It's not, by itself, project-related,
>
> Nor is it xref-related.

It's location-related, so to speak. Which live in xref, for now.

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

Not sure what you mean here.

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

Why would using M-x grep be better? I think it's better to provide an 
imperfect implementation that showcases the available features 
(bindings, commands, presentation).

That will better motivate third-party developers to improve on other 
aspects, such as precision. That's how most open-source projects get 
their contributors, anyway: when a feature works almost, but not 
exactly, right.

And one shouldn't discount Grep-based searched out of hand. For 
instance, a simple xref-find-definitions implementations that searches a 
set of directories for "def funcname", would be a lot better that the 
absolute nothing we provide out of the box to users who don't use etags.

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

M-x report-emacs-bug? That seems unrelated.