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 19:13:48 +0200 Message-ID: <5651F7CC.1030503@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <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> <5651597B.5090303@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 1448212458 841 80.91.229.3 (22 Nov 2015 17:14:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 17:14:18 +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 18:14:11 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 1a0YDH-0006Aq-Hm for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 18:14:07 +0100 Original-Received: from localhost ([::1]:56845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0YDH-0002ku-L6 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 12:14:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0YD5-0002ko-8V for emacs-devel@gnu.org; Sun, 22 Nov 2015 12:13:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0YD2-0003Qs-0U for emacs-devel@gnu.org; Sun, 22 Nov 2015 12:13:55 -0500 Original-Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:33181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0YD1-0003Ql-Pr for emacs-devel@gnu.org; Sun, 22 Nov 2015 12:13:51 -0500 Original-Received: by wmec201 with SMTP id c201so131726305wme.0 for ; Sun, 22 Nov 2015 09:13:51 -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=MnPGB5zdRtISiS5zvDNPa6St2jkTQ+YFYH5WaNvkHE8=; b=yygQSSyK/wG4XsA4byyl+2kzxcp7P4FYFgOXwhPSQDy61qt/HRV767P4FjFc29cuJX G+4IoYyOwM6BTnqHeEKIO+3+SsvDFwK4nfU5uP5LpGS5uGH6EotbdfX5hhA06ZLenoNM f5VAshi7W8vNflRV1vyuRlKjK/l87LiK7ZJmMCIeuJ3zz23AV0v+zoAiCpR9lkN403zR Dc1j5ei888G4FHjt5Kr92d4ZBE2lhIUL1WMq7oGTX4rUm9MqNf5c9Osk5Q7/8/I4Z6W5 Z60sZJ6xd0FlEq9ch/uMFBtzfRcANiGQl0Nrf8qCfEJojmaVjrvc68anfYFMKOolOE+d khuw== X-Received: by 10.28.189.5 with SMTP id n5mr14764612wmf.76.1448212431107; Sun, 22 Nov 2015 09:13:51 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id h7sm9459559wjz.7.2015.11.22.09.13.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Nov 2015 09:13:50 -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::22a 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:195040 Archived-At: On 11/22/2015 06:55 PM, John Wiegley wrote: > I'm still not sure why this means we need to encode restrictions within > project.el, rather than, say, in Ada mode, or whichever other mode is > providing information to project.el for the traversal of its related elements. I don't know what restrictions for Ada mode you have in mind. And how we might be able to mandate them, if not though project.el API. > I want as much freedom of expression as we can get away with, so long as the > default and expected use cases remain easily within reach. Freedom has a cost. In particular, if directories can be recursive or not, *each* API consumer will have to pay the price of supporting both ways. Like I already said, xref-collect-matches will have to grow another code path. And every other similar function will have to do that too. I have mentioned this multiple times already. Why don't we stop going in circles? > I feel, though, as if I've lost my grip on the vision for this project again. Maybe that's because you're only thinking in generals, and not examining the practical applications. Like the function mentioned above, and how it will have to change to accommodate your freedom. > As I understand it, it has two main components: > > 1. Ways to determine members of a project. > 2. Ways to usefully apply this information. > > I think our discussion so far have been in the area of #1 only, right? And is > that because we're stuck on how to define membership? From where I'm standing, it's because a certain person keeps derailing the discussion into making the API closer to how a "list of directories" usually works in Ada. And not because it's necessary for functionality (as we've discussed, recursive dirs + ignores can adequately describe a non-recursive set of dirs), but simply because it's convenient for a particular minority use case. > As long as, at the level of project.el, membership can optionally be a list of > "collection functions", this would allow near infinite expressiveness while > not detracting from the standard use cases of recursive and non-recursive > directory traversals. That's too vague. How will your "collection functions" mesh with using "find", so that most operations can stay performant in large projects? > I don't think we gain anything by "baking in" what membership means, and > disallowing flexible definitions. On the subject of what we gain, see above. > Such a road leads us to continuing to have > to extend and hack project.el's interface, as users run into the limits of > what it can express. Again: recursive dirs + ignores can adequately describe a non-recursive set of dirs. > Which Stefan already has done with ada-mode. We shouldn't > even be discussing ada-mode! There is a simple design path that can allow > Stefan to define his project contents however he wants. Such questions should > not even be an issue at this level of the API. If Stephen wants to define his project contents however he wants, without regard for any consumers, that cannot fit in any stable API definition.