From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Unified project interface Date: Sat, 11 Jul 2015 16:43:35 +0300 Message-ID: References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> <85iob2a2mm.fsf@stephe-leake.org> <5574D0AF.2090608@yandex.ru> <85zj4barkf.fsf@stephe-leake.org> <5577695F.70800@yandex.ru> <559C6E16.40701@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ea438dafcaf051a99ac7e X-Trace: ger.gmane.org 1436622224 17215 80.91.229.3 (11 Jul 2015 13:43:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jul 2015 13:43:44 +0000 (UTC) Cc: Stephen Leake , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 11 15:43:44 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 1ZDv4B-000730-Jv for ged-emacs-devel@m.gmane.org; Sat, 11 Jul 2015 15:43:43 +0200 Original-Received: from localhost ([::1]:48162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDv4A-0008Vt-W4 for ged-emacs-devel@m.gmane.org; Sat, 11 Jul 2015 09:43:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDv47-0008Vm-Bf for emacs-devel@gnu.org; Sat, 11 Jul 2015 09:43:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDv46-0004DD-63 for emacs-devel@gnu.org; Sat, 11 Jul 2015 09:43:39 -0400 Original-Received: from mail-ie0-x22e.google.com ([2607:f8b0:4001:c03::22e]:34715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDv45-0004D3-UW for emacs-devel@gnu.org; Sat, 11 Jul 2015 09:43:38 -0400 Original-Received: by iebmu5 with SMTP id mu5so210961401ieb.1 for ; Sat, 11 Jul 2015 06:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=43UJPBKBRyLQAKsMTGLwNeXZxEFZ+imINft0MZXBK3I=; b=Ox1bdTRBHlYGek4Rp89LOrhIggxhteJE1EItCw5kBudeunBpDNzk8IN3Qu5/qykKXF WtyvfniZCBcpBFRgHP3G6z5YYWaWgkIi3KxFxEg1sa54ObGRmtR99UhjIH5kRHw6mKyi eIJ65J7oVnw4+iyueCJbtdAVu/kfo74oNNe0hS2oXp2CzGgXPnLQaqhargEeBFSZSdqE xAhamo9S7hhXBhHRqKa3tRwETgPwkieg0XQkgLz6IlMHNzAK0Kj3IMepA+h5BxZXCcRp HqOyRRFMRH27cPdJu2/hVu0ptEcDrlykLNnDtRl8DduVREEnurt58grM6RpXWgEEiJth 7VLw== X-Received: by 10.107.130.231 with SMTP id m100mr7926163ioi.162.1436622215902; Sat, 11 Jul 2015 06:43:35 -0700 (PDT) Original-Received: by 10.107.134.16 with HTTP; Sat, 11 Jul 2015 06:43:35 -0700 (PDT) In-Reply-To: <559C6E16.40701@yandex.ru> X-Google-Sender-Auth: 7dvfWZ5_8DXwYI4DpBrpuj7t0Gw X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::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:187803 Archived-At: --001a113ea438dafcaf051a99ac7e Content-Type: text/plain; charset=UTF-8 I finally took a quick look at the current code (and the discussion so far) and I have a few remarks: * even within source directories it's useful to be able to exclude certain subdirs from project-level operations. How is this going to be handled? * it's not 100% clear to me what are major mode writes supposed to provide as "project implementations" * In 24.4 a `vc-root-dir` was added. Seems it overlaps a bit with `project.el` * how can Projectile (or a similar package) leverage `project.el`? On 8 July 2015 at 03:25, Dmitry Gutov wrote: > On 06/10/2015 01:31 AM, Dmitry Gutov wrote: > > If project-source-directories is a generic method, maybe we can say that >> its implementation should almost always (unless it really knows what >> it's doing) call the next applicable implementation. >> >> That implementation could be set up to dispatch based on the value of >> major-mode. >> > > I've pushed that to the branch 'scratch/project', please take a look. > > The split between "project directories" and "project source directories" > is not 100% necessary, but I think it can be useful, provided the semantic > difference between the two is clear. > > What I want to do with project-source-directories here, is to allow a > major mode to provide a default list (or, actually, a function that would > compute it, because `load-path' can change at runtime). > > This way, unless a project implementation explicitly overrides it, Elisp > authors will have the whole load-path used for searching. > > Maybe using a specialized implementation using &context is not the best > thing to do there. Alternatively, we can introduce a new variable (like > `project-source-directories-function'), and refer to it in the default > `project-source-directories' implementation, as well as its docstring. > > --001a113ea438dafcaf051a99ac7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I finally took a quick look at the current code (and the d= iscussion so far) and I have a few remarks:

* even withi= n source directories it's useful to be able to exclude certain subdirs = from project-level operations. How is this going to be handled?
*= it's not 100% clear to me what are major mode writes supposed to provi= de as "project implementations"
* In 24.4 a `vc-root-di= r` was added. Seems it overlaps a bit with `project.el`
* how can= Projectile (or a similar package) leverage `project.el`?

On 8 July 2015 at 03:25= , Dmitry Gutov <dgutov@yandex.ru> wrote:
On 06/10/2015 01:31 AM, Dmitry Gutov wrote:<= br>
If project-source-directories is a generic method, maybe we can say that its implementation should almost always (unless it really knows what
it's doing) call the next applicable implementation.

That implementation could be set up to dispatch based on the value of
major-mode.

 I've pushed that to the branch 'scratch/project', please take a= look.

The split between "project directories" and "project source = directories" is not 100% necessary, but I think it can be useful, prov= ided the semantic difference between the two is clear.

What I want to do with project-source-directories here, is to allow a major= mode to provide a default list (or, actually, a function that would comput= e it, because `load-path' can change at runtime).

This way, unless a project implementation explicitly overrides it, Elisp au= thors will have the whole load-path used for searching.

Maybe using a specialized implementation using &context is not the best= thing to do there. Alternatively, we can introduce a new variable (like `p= roject-source-directories-function'), and refer to it in the default `p= roject-source-directories' implementation, as well as its docstring.

--001a113ea438dafcaf051a99ac7e--