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, 22 Nov 2015 07:32:45 +0200 Message-ID: <5651537D.8040601@yandex.ru> References: <86pp1j4ejm.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> <56409F2D.9060300@yandex.ru> <86mvun9gz7.fsf@stephe-leake.org> <56415902.90103@yandex.ru> <86h9ktah9x.fsf@stephe-leake.org> <56429025.3070008@yandex.ru> <86r3jw4yrf.fsf@stephe-leake.org> <564340DC.5020008@yandex.ru> <86wptob2v6.fsf@stephe-leake.org> <5643CEAA.6000103@yandex.ru> <86si4bemyw.fsf@stephe-leake.org> <564478CA.20108@yandex.ru> <86y4e3c90y.fsf@stephe-leake.org> <56450CDB.9050604@yandex.ru> <564D3223.1050705@yandex.ru> <86h9kf655z.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 1448170381 23092 80.91.229.3 (22 Nov 2015 05:33:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 05:33:01 +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 Sun Nov 22 06:32:56 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 1a0NGh-0003KK-G2 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 06:32:55 +0100 Original-Received: from localhost ([::1]:54866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0NGh-0007tL-16 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 00:32:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0NGe-0007tC-0i for emacs-devel@gnu.org; Sun, 22 Nov 2015 00:32:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0NGa-0003K5-Pj for emacs-devel@gnu.org; Sun, 22 Nov 2015 00:32:51 -0500 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:37714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0NGa-0003Ji-Fe for emacs-devel@gnu.org; Sun, 22 Nov 2015 00:32:48 -0500 Original-Received: by wmww144 with SMTP id w144so66691700wmw.0 for ; Sat, 21 Nov 2015 21:32:47 -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=nmnzo+StpMJ+xYG/AOeihbzmi/NEWSkeseXkcGLNwOk=; b=QmXRMOipBErmWZ69uGjZ6Wr6MFmao8ierW6WYk8m4BjbKoq48UEIGNEsvwZcrJF2gd r1eO3ly6BkReBrSwDo3A+Fd8DgUCwlN55VzUHvqe7Wxc7ikeFGZHSVSWegLBV/xLbAFQ Fcw7XnzHswlSG03yXZAlVXI0+KR4ifc/AJteGGf/La2OstZsKsqB+m1t5aOTV+2zITJN S0prUpqfehPPXaKgHL01N+q3znTmbaWk38RUw1T8AG8k/5pd0qJsmXP3eTKjOKiDoVjJ 4dZA5IKjdB12RMJjh+1B0T9kp+QcZFVegalmzPg8HhE1c+9C1a1bJ/Rm/PjfF2Wgj5j/ dx8A== X-Received: by 10.194.23.73 with SMTP id k9mr14066351wjf.3.1448170367840; Sat, 21 Nov 2015 21:32:47 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id e83sm7015665wmc.23.2015.11.21.21.32.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 21:32:46 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <86h9kf655z.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::22c 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:194985 Archived-At: On 11/21/2015 12:03 PM, Stephen Leake wrote: >> For instance, in can include the test roots in there. Or, I don't >> know, some other kinds of directories that aren't supposed to be >> traversed recursively. > > Then it also needs to indicate which are recursive and which aren't. One > way is to return a cons (recursive-dirs . non-recursive-dirs). Those will be directories of different kinds, and the "non-recursive" (or, most-likely) "non-traversable" status would be reflected in their category name. For instance, some directory might contain the key config files of the project; its category, then, will be "config-file-are-here". I'm not sure it would be a good idea to have two directories belonging to the same set of categories, that the callers would have to treat differently WRT traversal. > What is the use case for this? For instance, in addition to the "project root" (let's imagine there's just one root), a Java project can have an src and test directories inside it. The backend could report that "src" belongs to the "source-roots" category, and "test" belongs to "test-roots" category. Then, provided there is a stable test file naming convention, we could define commands that would allow the user to jump between the source file and its test, and perform other related operations. > 1 is satisfied by project-all-roots (ie (append (project-roots prj) > (project-library-roots prj))) and project-ignores. Allowing > project-all-roots to return non-roots breaks this case. Basically, the caller would have to pass the returned value through `project-combine-directory'. Alternatively, we can have a helper like this: (defun project-directories-in-categories (project &rest categories) (project-combine-directories (cl-delete-if-not (lambda (dir) (cl-subsetp categories (project-categories project dir))) (project-directories project)))) Or, as yet another option, we can define `project-directories' to have this signature, and the project backend to implement it. But I'd prefer to have the helper. > 2 is not supported directly. It is not simple to get the list of all > directories from project-all-roots and project-ignores. I'm not convinced it's actually needed. Like discussed previously, the capability encourages slower implementations. Instead, where possible, the API consumers should combine 'find' with other programs. Even so, while it's "not simple", it perfectly possible to implement it on top of the API. So we can include it as a utility function, but there's no need to make it a method, for a backend to implement. > For Emacs 25, we should keep this as simple as possible; provide two > functions, one that returns all recursive roots and ignores, another > that returns a non-recursive list of all directories. Backends can > provide whichever is convenient; project.el can convert between them. And I'm against that: a) See above. b) Having only these two functions won't make it possible to have both project-find-regexp and project-or-libraries-find-regexp (or whatever its name will be). I've explained why its beneficial to have both, and the distinction between them. >> - If we're only documenting the "categories" key inside >> project-metadata, why not have a project-directory-categories method >> instead? We can add the -metadata method, too, now or later. > > This should wait for Emacs 26; we don't have a solid proposal. I thought the idea is pretty simple. What would you like me to clarify?