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 15:40:05 +0300 Message-ID: <55FD57A5.4030608@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <55F8F2FA.6060902@yandex.ru> <867fnq1oe9.fsf@stephe-leake.org> <86twquzc33.fsf@stephe-leake.org> <55F98538.7040700@yandex.ru> <86io7az4h3.fsf@stephe-leake.org> <55FAF54B.2030306@yandex.ru> <86pp1fwsxq.fsf_-_@stephe-leake.org> <55FCA78B.3090803@yandex.ru> <86lhc2wr2m.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 1442666454 27243 80.91.229.3 (19 Sep 2015 12:40:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Sep 2015 12:40:54 +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 14:40:52 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 1ZdHRi-0000OD-Fw for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 14:40:50 +0200 Original-Received: from localhost ([::1]:45750 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdHRh-0004bH-Um for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 08:40:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdHRR-0004ay-82 for emacs-devel@gnu.org; Sat, 19 Sep 2015 08:40:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdHRN-0000Bh-Ux for emacs-devel@gnu.org; Sat, 19 Sep 2015 08:40:33 -0400 Original-Received: from mail-la0-x22c.google.com ([2a00:1450:4010:c03::22c]:35074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdHRN-0000BC-Dt for emacs-devel@gnu.org; Sat, 19 Sep 2015 08:40:29 -0400 Original-Received: by lagj9 with SMTP id j9so44829067lag.2 for ; Sat, 19 Sep 2015 05:40:28 -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=5bU/6FuIFMMq45ygcm3bQZM+xf2zhco2+M90JZNhRqM=; b=WX/TGG+g4q/hnmDFQzNZhDuGlXzgS71izedJpBtKRZqVgdu0LV3SVf3Ww3wuCj1SOw VxTu7ht0F6dkYJc8ur5OCKhXb8Asumx1cAGvQhePmkJeQYhIgPIXjgmLU+qjTtXViM+0 btOnca9JaiMKQu5xWWeKdYHdLnGcb8KHBKyEPxmERQyGSdeJlOqBYUlu/ke/U9E43b5B piU8VjQPWmaCx9FJX+AZbZ0boCyXBIBd4kjrhvTx4jIq9yXjBcZq4Qw4I7RnTtE93j6+ g4kievciYxVdi3tYJjrNhhm8DaKAcZ2Lyb+OIrpQ+UvGK3+cTFDXY7vCAiKBbVSkn8zk yPAA== X-Received: by 10.152.9.135 with SMTP id z7mr4968881laa.12.1442666428681; Sat, 19 Sep 2015 05:40:28 -0700 (PDT) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id xt10sm2068768lbb.9.2015.09.19.05.40.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2015 05:40:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86lhc2wr2m.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::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:190100 Archived-At: On 09/19/2015 03:07 PM, Stephen Leake wrote: > "purely recursive" means no element of the path is a subdirectory of > another element. Let's call it "non-redundant". > It is quite possible for a project to have an include path like > "root/include/dir1 root/include/dir1/dir2". Yes. >> I'm pretty sure that even if that were the case, it could be a >> good-enough feature, just one with undesirable quirks. > > Not a good advertisement for the project API. If I saw that statement in > the project user guide, I'd stop reading, and go learn about EDE. Sure, EDE has no quirks at all. > Failure to go to an include file would certainly be "undesireable". I > don't think "quirk" is the right term, though; "bug" and "bad design" > are more appropriate. Why do you think "failure to go to an include file" would be among those quirks? Rather, I would imagine that if #include didn't allow files in subdirectories, the main problem with the find-file-in-includes function that was implemented as if it did, would be that it would allow to go to *too* many files, not too few. So, false positives, not false negatives. >>> That's an argument for providing project-flat-search-path (overkill for >>> this use case, but not harmfull), >> >> I don't think it is. > > Interesting. First you admit that your approach is wrong, then you deny > that another approach would work, without any proof. Hence the word "think". But how would it help? Redundant or not, C_INCLUDE_PATH is "recursive" like I've described in the previous message. How would a "project-flat-search-path" relate to it? >> I admit >> returning redundant elements is not documented, but for now it's just >> an idea, not something set in stone. Eventually it'll need to be >> documented, whichever way the decision comes out. > > What's wrong with picking one now, and documenting that? That at least > gives us a better defined base to start from. On the one hand, project-search-path being non-redundant would be more useful for the currently implemented commands, as well as find-file-in-project. One the other hand, if we add a second generic in the future, project-search-path seems like a better name for the *redundant* one of the two. Don't you think? But changing this generic's semantics later might not be an option anymore. >> 100% agreement, except for "options in the API to choose among the >> different semantics". It's better to only have to deal with one >> semantics, as long as the result can be just as powerful. > > Interesting; how to say "yes" and "no" in the same paragraph. That's how I read that paragraph: "Sure, naturally, yeah... waaait a minute!" >> The statement in parens above seems like a recipe for disaster. How >> would a function know what the backend is including? Will it have to >> provide different implementations for different backends? Remember, >> we're striving for "backend-agnostic" here. > > Precisely my point; ...OK? > I'm glad you agree. So why do you refuse to fix the > documentation to be clear? Because if we "fix" it that way now, we might decide that the matter is closed. Whereas a proper fix shouldn't be too hard, and with find-file-in-project implemented, find-file-in-includes would be just one step away. > savannah Emacs git. Fair enough. Somewhere in etc/?