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:58:19 +0200 Message-ID: <5651597B.5090303@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <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> <56515443.70408@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 1448171925 10333 80.91.229.3 (22 Nov 2015 05:58:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 05:58:45 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 06:58:41 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 1a0Nfb-0008No-Lh for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 06:58:39 +0100 Original-Received: from localhost ([::1]:54913 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0Nfb-0004El-4Z for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 00:58:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0NfN-0004Du-Ke for emacs-devel@gnu.org; Sun, 22 Nov 2015 00:58:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0NfK-00005C-E1 for emacs-devel@gnu.org; Sun, 22 Nov 2015 00:58:25 -0500 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:38856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0NfK-0008WH-7D for emacs-devel@gnu.org; Sun, 22 Nov 2015 00:58:22 -0500 Original-Received: by wmec201 with SMTP id c201so67200111wme.1 for ; Sat, 21 Nov 2015 21:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4JhTWNgRLh+aKT5SKebmr5VbffHdPamNLXdjDUVy+WQ=; b=Y0pwnb5vk5cFoZibrwJKajrYeKqgPqVS39YkN668d8zrlwHRAByDO5MXflkqQrvkTJ 3YsvnSh9W8Pz18r4kUGJa7Um0VYxfSgzIn++sr1dF9mva+M8sW/rRzuciUyEPwfivfKG F7Q1Cn30n2Bd7zvSQL1gGjB+vJ66AaJ5sfR0dtFK7sAuEWRI8AB+vsntpLeBrpSpyA7b gfexzdVGDK5XX+xsQo/Tphjh1tBmFbXXkfOjw6wkiLr0MDbgjhd3TIqXOekxkR9bVR6I WVAfZvMcRq5ovYjaQThqR/nUuH+JQqse2CTjZzn5uVzXkfqc1X1fbGx1Jkdw5IrLTm+1 5DTg== X-Received: by 10.28.224.86 with SMTP id x83mr12360804wmg.36.1448171901676; Sat, 21 Nov 2015 21:58:21 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id it4sm7229150wjb.0.2015.11.21.21.58.19 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 21:58:20 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: 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:194988 Archived-At: On 11/22/2015 07:43 AM, John Wiegley wrote: > Could you clarify? I thought the metadata approach give us a freedom that > implied the exact opposite, compared to a recursive vs. non-recursive only > vector. A sloppy consumer of the API can disregard the "recursiveness" metadata key, and traverse the directories in only one of the possible ways. For instance, Stephen is used to non-recursive traversal of directories, in Ada projects. So he could write commands that do not support recursive traversal (maybe left as a TODO), but would still work fine with his Ada project backend. As a result, their universal applicability would be limited. Or, vice versa, some other third-party package can only expect the "recursive" kind of directories, and traverse them that way. That would work fine on most projects out there, but would lead to undesirable effects if someone tried to use it with the Ada backend. IME, freedom rarely implies correctness.