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: project.el semantics Date: Mon, 9 Nov 2015 15:27:09 +0200 Message-ID: <56409F2D.9060300@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <86mvwn11u1.fsf@stephe-leake.org> <55F8E451.9080902@yandex.ru> <86bnd21q0r.fsf@stephe-leake.org> <55F97EA2.9000408@yandex.ru> <86mvwmz58h.fsf@stephe-leake.org> <55F9A5F8.1030505@yandex.ru> <86pp1ixem2.fsf@stephe-leake.org> <55FAFC36.5010506@yandex.ru> <86twqrww0u.fsf_-_@stephe-leake.org> <563EA9B9.5080404@yandex.ru> <86vb9dufs0.fsf@stephe-leake.org> <563F4915.1080008@yandex.ru> <867flrbksb.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 1447075662 3606 80.91.229.3 (9 Nov 2015 13:27:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 13:27:42 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 14:27:36 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 1ZvmTn-0003v9-EW for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 14:27:27 +0100 Original-Received: from localhost ([::1]:52702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvmTh-00082m-LO for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 08:27:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvmTb-00082B-Vz for emacs-devel@gnu.org; Mon, 09 Nov 2015 08:27:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvmTY-0002wj-JQ for emacs-devel@gnu.org; Mon, 09 Nov 2015 08:27:15 -0500 Original-Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:38379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvmTY-0002wd-AA for emacs-devel@gnu.org; Mon, 09 Nov 2015 08:27:12 -0500 Original-Received: by wmec201 with SMTP id c201so69635496wme.1 for ; Mon, 09 Nov 2015 05:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Di8l0FzS/86vUGqTdRpa0xlk17OLJPsCVCPxis7cmy4=; b=g9jiZeuBVQIFniwJmRFeE1vHPp5zmKujiCY1YYrvh9+8RIbb+3bV31SBp1AnnyWXK+ JfP/onN8qjoOSlIBXm1J01VkydmB4Ob+bZZHCQ69lzYQ4JM1vgh8S7q5dgoH7ORVfQRL MiSWfR4kaZBU1oWRF1g+DhCl/154v1CL7tW7GxyMThxHRuDvotj07WPxfgGbqKnSgOZP Dtf1WqoAOaAJ+Jz+P/amd+Oc/XcTT0ku0KVlsgjWmuwltfM2D4OCyrkroi5HST449UH5 9WElfzoSjmXu6qWyOa8qcHTbdnV57mBI0veMSREue5zqZu6Tm8awgKoH82ETegqzd2oY Ew+Q== X-Received: by 10.194.174.202 with SMTP id bu10mr36256446wjc.74.1447075631811; Mon, 09 Nov 2015 05:27:11 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id lb2sm15465231wjc.15.2015.11.09.05.27.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2015 05:27:11 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <867flrbksb.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:c09::235 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:193705 Archived-At: On 11/09/2015 11:10 AM, Stephen Leake wrote: > I don't understand; you seem to be saying a "library" is _not_ a > "dependency". That's not consistent with common usage. I'm saying we'd probably want to treat "managed project dependencies" differently from "library dependencies". And if we were to introduce a "dependencies" accessor, I think it would return a list of projects, not directories. > "Dependency" includes system libraries, other managed projects, and > anything else the user wants to search. > > Why do you insist on the less general term? Because it's a less loaded one. http://www.jetbrains.org/intellij/sdk/docs/reference_guide/project_model.html also uses the term "library" in a similar fashion, so I think it will be clear enough. > The user has the freedom to do whatever they want. The point is to have > clearly defined semantics, so the user at least knows what the intent of > each of these functions is. For now, the distinction is "you want to edit this" vs "you don't want to edit this". >>> The default implementation of project-library-roots makes the lists >>> disjoint, so the doc strings should say that. >> >> Doesn't it? It says "outside". > > True; but I did not understand what you meant by that; it's not common > project terminology. I think "dependency" is much more widely > understood. I'm using "outside" as "directory terminology". We seem to approach this from different directions: I think that the user first decides what their "project roots" will be, and *then* designates a certain set of directories that also contain related files, as "library roots". >> I think "list of directories outside of the project" is pretty clear. > > You have two data points on this; insisting that yours is the only one > that matters is simply not helpful. Yes, sorry. You repeated the complaint, so I just repeated the answer. > It would be helpful if others would contribute here. Absolutely. I keep waiting for more people to join the discussion at this level of detail. John, would you like to weigh in? This is one of the issues we'd might want to decide on before the freeze. > Suggested rewording: > > "Return the list of directory roots belonging to the current project. > This excludes project dependencies. But do we want to exclude project dependencies, always? This might contradict the third paragraph: sometimes, you edit certain dependencies together with the project. > Most often it's just one directory, which contains the project > file and everything else in the project. But in more advanced > configurations, a project can span multiple directories. > > One rule of thumb for whether to include a directory here, and not > in `project-library-roots', is whether its contents are meant to > be edited together with the rest of the project. > > If a directory contains a separate project, it belongs in > `project-library-roots'. As stated, I'm not sure about this. > Functions that use project-roots and/or project-library-roots: > > elisp--xref-find-references both > etags--xref-find-references both These are different implementations for the same command: xref-find-references. > project-find-regexp only project-roots > project-or-libraries-find-regexp both > > (I thought there were more; I guess I was thinking of my own code) > > It is reasonable to provide a way to control what paths are searched, > but this is cumbersome and inconsistent. Inconsistent, yes. Somewhat. If we're walking about the last two, how would you change them? Rename to project-without-libtaries-find-regexp and project-find-regexp? IME, the former will be the one that the user will prefer most of the time. > Hmm. There's a "TODO" in etags--xref-find-references that says it > should be merged with elisp--xref-find-references; it's the same code. > So one solution would be to delete those two, and provide a new > function: > > (defun project-find-references (symbol &optional paths) I'll get around to it in a short while, but the idea is that the xref-find-references implementation based on project+grep is just the default one (and it will be one function). There will also be different, more specialized implementations possible, and the entry point for all of these is still going to be called xref-find-references. > "... > PATHS is one of: > 'top-level - only the top-level project > 'dependencies - only the dependencies > 'both - both (the default)" > > and change project-find-regexp to match. > > Or provide project-find-references and > project-or-libraries-find-references. This kind of goes against the idea of providing an implementation for the predefined interface. So, yes, etags--xref-find-references searches both the project roots and the libraries, and ideally the user would choose, but I'm not sure where to ask them. Should we expose these semantics in the xref-find-references interface somehow? >> That implies having to create a separate project implementation for >> every language, making vc-project utterly useless. > > Only for languages that imply a path of some sort. In which case that > path is more useful than using "path = vc root". Most languages do, I think. > vc projects are useful in situations where there is neither a language > defined path nor a build system project file that defines a path. That's > pretty rare for me, but they are not "utterly useless". All right, I can understand this viewpoint. >> You'd also have to create yet-another kind of project implementations, >> for multi-language projects. > > That's true anyway. Not really. If the is a hook that will return library roots for different languages, a given project implementation can use them all. Should I write a proof-of-concept? Where I come from, it's common enough to have several "project files", so to speak, at the top of a project, coming from different languages. For instance, having both Gemfile and package.json. >> Note that determining whether the a given directory tree has Elisp >> files inside is not 100% reliable, outside of traversing it whole. > > I didn't say anything about "directories with elisp files"; just about > elisp-mode. I don't think we should have "current project" depend on the current buffer. Only on the current directory. Or be picked explicitly by the user (not implemented), and be "current" for the whole Emacs session. >> But if we pick some detection mechanism, (and we'd have to, for >> Elisp-project detection), we can just as well use it to call >> elisp-library-roots globally and make it auto-detect whether the >> current project is applicable. > > That's what EDE does; we should improve that rather than duplicate it. Not really. EDE chooses from a list of applicable project implementations. It has no hooks for "libraries", AFAIK. > I am proposing something much simpler; a project-find-file that uses the > mode of the current buffer to help pick the project. I dislike that. The project should be the same, whether we're visiting an .el file, or the README file beside it. >> At the moment, I feel that this approach would be a cop-out. > > How is it worse than the current cop-out of setting > project-library-roots-function in elisp-mode? Not worse, it's just bad on its own. project-library-roots-function being buffer-local is a problem. Hence that FIXME. And hence the proposals to improve it that I've written in the previous two messages (one of which you haven't replied to yet).