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: Sun, 8 Nov 2015 15:07:33 +0200 Message-ID: <563F4915.1080008@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> 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 1446988075 28384 80.91.229.3 (8 Nov 2015 13:07:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 13:07:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 14:07:46 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 1ZvPhB-0006J4-7W for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 14:07:45 +0100 Original-Received: from localhost ([::1]:47356 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvPhA-0007n5-E8 for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 08:07:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvPh5-0007ml-WF for emacs-devel@gnu.org; Sun, 08 Nov 2015 08:07:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvPh2-0000Cj-OF for emacs-devel@gnu.org; Sun, 08 Nov 2015 08:07:39 -0500 Original-Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:34049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvPh2-0000Cf-ER for emacs-devel@gnu.org; Sun, 08 Nov 2015 08:07:36 -0500 Original-Received: by wikq8 with SMTP id q8so53802579wik.1 for ; Sun, 08 Nov 2015 05:07:35 -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=v+62Zt/c//7MEakhqtPcU4xZQd9z0XtLPawU32f/9Lw=; b=Do0aZGdSjsQgnqY/ufrSCTaMIfvxvS4NBQ/6jD7QHP/XlzHryeQL4BxqDn+yRacei9 XAHNDAIxuJmUzrQaVlAiTRA387qYAP/gRMDixEZCk8IPR1A8lU9gTyiH+0xzu1meTFWA I06DFDkc7txGjDcxWoo4cuVu1wco9lFX+M1rN8utnjCH54LQkGd/JwQHjrvtsiYIRFFg nwa6AtYwTLxMKxs0TFbuDXEkQW89vuW86i9dYBMj194z3G6YR9mnEf2B4HNifEeSTqPg ju/lpU9dvQZ35epONCNcBg4XpEJGS6GoH6u2pZ+ki0l2c1ZroiLxzfNkzodInmVW8PgO /ltA== X-Received: by 10.194.11.67 with SMTP id o3mr3967765wjb.3.1446988055819; Sun, 08 Nov 2015 05:07:35 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id v191sm8787650wmd.24.2015.11.08.05.07.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2015 05:07:34 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <86vb9dufs0.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::234 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:193607 Archived-At: On 11/08/2015 09:11 AM, Stephen Leake wrote: > 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. It would be impossible for project-library-roots-function to implement the "outside of the current project" part of semantics, unless we pass it the current project. And then, what's the point? It's just as easy to call project-subtract-directories from the default project-library-roots impl. Any other inconsistencies? (I've pushed a minor update now, but it's probably unrelated to your concerns). > 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. I think we might want to introduce the notion of project dependencies later, and then we'd have to call some of library-roots, again, library roots, to distinguish from the dependencies. Better to defer that change. Note that you currently have the freedom to include the checked out dependent projects in the project-roots (if you edit these projects together). > The default implementation of project-library-roots makes the lists > disjoint, so the doc strings should say that. Doesn't it? It says "outside". > 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". I think "list of directories outside of the project" is pretty clear. > The advice in project-roots on "include here but not there" should > mention top-level vs dependencies. Could you rephrase that? I'm not sure I follow. > On the other hand, `project-library-roots ((project (head vc))' does > _not_ make them disjoint, so there is a bug here somewhere. Fixed, thanks for pointing that out. > The new function `project-find-regexp' is not consistent with other > usage; other project- search functions search both top level and > dependencies. Sorry, what other project- search functions? Do you mean xref-find-references? Note that we also have project-or-libraries-find-regexp. IME, when doing a regexp search across the project, you aren't interested in the library code, most of the time. >> 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. `project-library-roots ((project (head vc))' knows nothing of library roots, however, aside from the local variable that's supposed to be set by the user. > No other language mode sets project-library-roots-function. There is etags-library-roots, however. It's not language-specific, but, again, vc-project doesn't know about it. There is also ruby-library-roots already brewing in my head. > 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; That implies having to create a separate project implementation for every language, making vc-project utterly useless. You'd also have to create yet-another kind of project implementations, for multi-language projects. Note that determining whether the a given directory tree has Elisp files inside is not 100% reliable, outside of traversing it whole. 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. Like described in the FIXME. > then elisp-project can override > project-library-roots to return load-path; it could also add the emacs C > sources if they are available. At the moment, I feel that this approach would be a cop-out. But it's definitely an option. > 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 don't think we ever call project-library-roots-function from anywhere but project-library-roots (*). And that requires the presence of the current project. > I would delete the advice that overriding functions should use > project-library-roots-function; the main reason to override is to do > something different. (*) Hence, if we go your way, there seems to be no need for project-library-roots-function. > 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. Thanks, I'll merge after your next reply.