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 22:11:31 +0200 Message-ID: <563FAC73.9060908@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> 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 1447013519 24446 80.91.229.3 (8 Nov 2015 20:11:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 20:11:59 +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 21:11:55 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 1ZvWJc-00048c-Mr for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 21:11:53 +0100 Original-Received: from localhost ([::1]:48697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvWJc-0007DO-3q for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 15:11:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvWJN-0007CV-PA for emacs-devel@gnu.org; Sun, 08 Nov 2015 15:11:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvWJK-00068D-DC for emacs-devel@gnu.org; Sun, 08 Nov 2015 15:11:37 -0500 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:37861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvWJK-000687-78 for emacs-devel@gnu.org; Sun, 08 Nov 2015 15:11:34 -0500 Original-Received: by wmww144 with SMTP id w144so16136684wmw.0 for ; Sun, 08 Nov 2015 12:11:33 -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=z/5CY1vgBFC0GUk5cIhONx0Ha5qYKXDgNIUi+f1qBz8=; b=hfJZNVG1urXrUgZfHmBQXYR59FmPT7GyC5uLJC7CDjLs2kY5MQRQV3rD09gksih6Dy KwtQeiB5uVlyuYULuDz8B8WfapfFXNvFQ56PWFzbrlzk7/oLOU9gjrNW/pxv6mkfC1qb FM3Vf4iYWCZzeUQ68OH6xvYcz2FLoqHfmLcJ9YJz8iG5StDGCYfsyzeOcQe9pxb/0nYp o7qHj49qq9kDD5xsPYL/WO9SAa7tBSA+t1+P4zGXwrDmh1nq1RuMBD1HOSUpFfucGK4L ngqRxi4FOs5Koq+U+PXylyokTHim0BaRAVdRH7ac9sMCFcHr01UO5CbMR0+R1sbbP7zH fFDg== X-Received: by 10.28.143.144 with SMTP id r138mr23155673wmd.100.1447013493417; Sun, 08 Nov 2015 12:11:33 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id s2sm10393708wmd.13.2015.11.08.12.11.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2015 12:11:32 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <563F4915.1080008@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22e 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:193651 Archived-At: On 11/08/2015 03:07 PM, Dmitry Gutov wrote: > On 11/08/2015 09:11 AM, Stephen Leake wrote: >> 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. > ... >> 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. I can also propose another change: if project-library-roots-function, in your opinion, complicates the project API unnecessarily, we can fold it into project-vc-library-roots, for now (and make that variable a hook). In practice, other project implementation would still be able to use it, and if we see that happen, we can promote it formally to a variable independent from vc-project (with a rename). We'd have to figure out which of the roots to visit to read .dir-locals.el, though. In this scenario, project-vc-library-roots would be allowed to contain both strings and functions, and the functions will normally be put into the global value.