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: Sat, 19 Sep 2015 03:17:36 +0300 Message-ID: <55FCA9A0.6060100@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> 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 1442621905 16473 80.91.229.3 (19 Sep 2015 00:18:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Sep 2015 00:18:25 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 19 02:18:20 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 1Zd5r9-00045e-TJ for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 02:18:20 +0200 Original-Received: from localhost ([::1]:42662 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd5r9-0006pm-3c for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2015 20:18:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd5qu-0006pY-5d for emacs-devel@gnu.org; Fri, 18 Sep 2015 20:18:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zd5qr-0006c2-1K for emacs-devel@gnu.org; Fri, 18 Sep 2015 20:18:04 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:37528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd5qq-0006bu-Qa for emacs-devel@gnu.org; Fri, 18 Sep 2015 20:18:00 -0400 Original-Received: by wicfx3 with SMTP id fx3so48664550wic.0 for ; Fri, 18 Sep 2015 17:18:00 -0700 (PDT) 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=vXvJtzBpcJznSsEWMFV9LNv8pQXWg2bThC4tJo4JqH0=; b=hVsOBrFI1lBo185zGlrAbTiMFlqX2f4xg831OGEF8p7QtsKE4D3Dp52NFed0d/xDTn 4zZGQJzaBDYayiC7FyuGN+S4W9ZP7XLAekwo+EiPo8BIC5SNQLaMyR7a5F7KnymFvAoJ AJvY0PKtU6LFN7xoeybgiVO6zWhON2aXgR3jVDiIhKaVh/XRFgyxksQ5xypB5fhkbhXI dAMEzbdbHYE4PDVwscLt51hDeDolgme7O1YGTa3vvyE2ujrQnamseEpeXzwgeMzyFbMp wY+5eq/gycorwusET7Gn91+yAl4i8SVfCjPyEcEg/lfsDp1xumQpFu/NAg/iVWWwCdqx EuDQ== X-Received: by 10.194.203.42 with SMTP id kn10mr10123368wjc.38.1442621880006; Fri, 18 Sep 2015 17:18:00 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id lf10sm11290149wjb.23.2015.09.18.17.17.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 17:17:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86twqrww0u.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:c05::233 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:190069 Archived-At: On 09/18/2015 07:08 PM, Stephen Leake wrote: > In order to use the API correctly, the semantics of each call must be > well-defined. No argument here. > That means it must be possible to tell from the API as defined by > project.el (and some future project.texi) what functions to call for > these two uses. They cannot rely on vague guesses about what some > backend might do, or what the user might want. Yes, we need more documentation. Please simply consider the grand-parent email as bringing up an example of another use-case we might want to support. > That means project-search-path should be clearly defined to be either > purely recursive or not, so client code and project backends know > whether to weed out duplicates or not. Let's call it "redundant", or "non-redundant". The issue seems different from the "flat" search-path we've discussed previously. > It also means the distinction between project-search-path and > project-roots must be more clearly defined. Sure. We need more clarity WRT to redundancy in the search path, maybe better docstrings (although it's not immediately clear to me how to improve the current wording), and some good examples in the manual. > If there are use cases where different search paths are desired for > different purposes (such as "source" vs "documentation" above), the > the project API must provide a clear mechanism to distinguish those > cases, so the appropriate search path can be returned. But what are those different purposes? So far, the distinction as I understand it is that search-path contains actual source files, and project-roots can contain anything else. So it's just source files vs any files. > The current doc strings for project-search-path and project-roots do not > make that clear, and the way they are used and implemented in current > code makes project-roots purely redundant (no code would be harmed by > simply deleting it, and some would be improved thru reduced redundancy). The default implementations don't have enough information to do better. Would you delete the default project-search-path implementation? Then what will the VC-backend implementation of it look like?