From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: project.el semantics Date: Sun, 08 Nov 2015 01:11:27 -0600 Message-ID: <86vb9dufs0.fsf@stephe-leake.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446966735 20165 80.91.229.3 (8 Nov 2015 07:12:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 07:12:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 08:11:59 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 1ZvK8s-0001dY-UL for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 08:11:59 +0100 Original-Received: from localhost ([::1]:46463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvK8s-0008Mg-1j for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 02:11:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvK8o-0008MQ-5w for emacs-devel@gnu.org; Sun, 08 Nov 2015 02:11:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvK8k-0007ol-Vg for emacs-devel@gnu.org; Sun, 08 Nov 2015 02:11:54 -0500 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:53737) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZvK8k-0007oe-ON for emacs-devel@gnu.org; Sun, 08 Nov 2015 02:11:50 -0500 Original-Received: (qmail 29088 invoked by uid 0); 8 Nov 2015 07:11:46 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 8 Nov 2015 07:11:46 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id evBe1r00E2UdiVW01vBhWu; Sun, 08 Nov 2015 00:11:46 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=vaJtXVxTAAAA:8 a=norsNLuxT_c25P3lueAA:9 Original-Received: from [76.218.37.33] (port=58022 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZvK8Y-0006Hc-5P; Sun, 08 Nov 2015 00:11:38 -0700 In-Reply-To: <563EA9B9.5080404@yandex.ru> (Dmitry Gutov's message of "Sun, 8 Nov 2015 03:47:37 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.33.93 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:193586 Archived-At: Dmitry Gutov writes: > Please see the commit 9776972 inside the branch project-next. I intend > to merge it into master in a day or two. The new project.el has: (defvar project-library-roots-function 'etags-library-roots "Function that returns a list of library roots. It should return a list of directories that contain source files related to the current buffer. Depending on the language, it should include the headers search path, load path, class path, and so on. And later: (cl-defgeneric project-library-roots (project) "Return the list of source root directories. It's the list of directories outside of the current project that contain related source files. Project-specific version of `project-library-roots-function', which see. Unless it knows better, a specialized implementation should use the value returned by that function." These are inconsistent. It would be best for the project-library-roots-function doc string to _only_ refer to cl-defgeneric (ie, "default implementation of `project-libary-roots'"), so you don't have duplicate documentation that gets out of sync. And then: (cl-defgeneric project-roots (project) "Return the list of directory roots belonging to the current 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. The rule of tumb 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. The directory names should be absolute.") You seem to be trying to establish a difference between "a single project" and "the libraries used by a project". Better terminology would be "top level project" and "dependencies"; not all dependencies are libraries. It would be helpful to make this distinction more explicit. The default implementation of project-library-roots makes the lists disjoint, so the doc strings should say that. In particular, "load path" and "class path" contain _both_ the top level project and the dependencies, so project-library-roots should _not_ be the same as "load path" or "class path". The advice in project-roots on "include here but not there" should mention top-level vs dependencies. On the other hand, `project-library-roots ((project (head vc))' does _not_ make them disjoint, so there is a bug here somewhere. The new function `project-find-regexp' is not consistent with other usage; other project- search functions search both top level and dependencies. > Also see the FIXME commentary above project-library-roots-function; > it's waiting for the public opinion. Though it's not really about > source vs documentation as much as about different kinds of sources. That FIXME: says, in part: ;; FIXME: Using the current approach, we don't have access to the ;; "library roots" of language A from buffers of language B, which ;; seems desirable in multi-language projects, at least for some ;; potential uses, like "jump to a file in project or library". emacs-lisp-mode makes project-library-roots-function buffer-local, which makes it language-specific. That's an argument for overriding the default implementation of project-library-roots to do something more useful. Which is what `project-library-roots ((project (head vc))' does, for example. Which means that the behavior of projects in an elisp file that happens to be in a vc directory is different from one that is not. No other language mode sets project-library-roots-function. The root cause of this problem is trying to infer a project in an elisp file. This makes sense in general, because an elisp file implies the use of load-path, which is the main part of defining a project. A better way is to provide a project-find-function that returns an elisp-project object in elisp buffers; then elisp-project can override project-library-roots to return load-path; it could also add the emacs C sources if they are available. That leaves the default behavior in non-elisp files that are also not in a vc directory; they currently use 'etags-library-roots. You could change the default definition of project-library-roots to use etags-library-roots directly, but it seems better to have a variable for this. I would delete the advice that overriding functions should use project-library-roots-function; the main reason to override is to do something different. I have no problems merging this branch to master; it makes things better in most places, and no worse in any. Howver, it would be best to clean up the inconsistencies above first. -- -- Stephe