[Top][All Lists]

[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: Thu, 30 Jul 2015 01:51:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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

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

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.

reply via email to

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