From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Unified project interface Date: Thu, 30 Jul 2015 01:51:56 +0300 Message-ID: <55B9590C.3080108@yandex.ru> References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> <85iob2a2mm.fsf@stephe-leake.org> <55B2CDA4.8020207@yandex.ru> <868ua5caz6.fsf@stephe-leake.org> <55B441DD.9060806@yandex.ru> <86zj2jb1tx.fsf@stephe-leake.org> <55B517AC.5020401@yandex.ru> <86oaiybvbf.fsf@stephe-leake.org> <55B62B53.5060003@yandex.ru> <861tftaxgx.fsf@stephe-leake.org> <55B78F49.6010101@yandex.ru> <868ua09s1y.fsf@stephe-leake.org> <55B7CD86.20306@yandex.ru> <86oaiv8zqn.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1438210359 13967 80.91.229.3 (29 Jul 2015 22:52:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 22:52:39 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 30 00:52:27 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZKaCy-0007Ss-MZ for ged-emacs-devel@m.gmane.org; Thu, 30 Jul 2015 00:52:20 +0200 Original-Received: from localhost ([::1]:37260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKaCx-0007r8-US for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 18:52:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKaCk-0007qp-M0 for emacs-devel@gnu.org; Wed, 29 Jul 2015 18:52:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKaCg-00032q-Qy for emacs-devel@gnu.org; Wed, 29 Jul 2015 18:52:05 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:35987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKaCg-00031d-Fr for emacs-devel@gnu.org; Wed, 29 Jul 2015 18:52:02 -0400 Original-Received: by wicgb10 with SMTP id gb10so220128277wic.1 for ; Wed, 29 Jul 2015 15:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=D4WLPZFuKVtcC1v+yttlzYs3vfgOWBUvpZnsr4MRvuw=; b=xe+za1lttgvOQAgVPpAKqSc6kEieTwXNFCNOzMJE4Eag+J/eXzmcHr60rjPOA2WfWB 5++Pyl7VhaqFqgmuNX7neEvd9u1KbfkxGtrbemEXyy5RsJ0O/uqIx+rcomKAcrbs91As 4lf6KjM1nbg76dRPxo1fXIk2HqKEInnFfZbRRNgFXowrfwdFJ8KyA1mEr+ZFLEhsJJLL E0WF8i0RP+2ibROInD32ggtizdb6o78GdVTtN88S3MP9/u64Fg9BJC/wJZ5P61D/uwJJ GEss92B8Xn4Z47FvjejBevLEfv68p+7W/pQBaZDViNdCpire73AdvsBQUtyyzq/fpzsB D/KA== X-Received: by 10.180.37.200 with SMTP id a8mr140632wik.26.1438210319401; Wed, 29 Jul 2015 15:51:59 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id h9sm40797169wjx.20.2015.07.29.15.51.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2015 15:51:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <86oaiv8zqn.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188179 Archived-At: 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 defaulted to the > identifier at point. M-x report-emacs-bug? That seems unrelated.