From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: project.el semantics Date: Sat, 19 Sep 2015 07:07:13 -0500 Message-ID: <86lhc2wr2m.fsf@stephe-leake.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442664498 31884 80.91.229.3 (19 Sep 2015 12:08:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Sep 2015 12:08:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 19 14:08:07 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 1ZdGw2-0007Sp-Sn for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 14:08:07 +0200 Original-Received: from localhost ([::1]:45610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdGw2-0007EJ-9z for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 08:08:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdGvp-0007E3-F3 for emacs-devel@gnu.org; Sat, 19 Sep 2015 08:07:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdGvk-00016Q-BU for emacs-devel@gnu.org; Sat, 19 Sep 2015 08:07:53 -0400 Original-Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55]:43999) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZdGvk-00015X-4g for emacs-devel@gnu.org; Sat, 19 Sep 2015 08:07:48 -0400 Original-Received: (qmail 22955 invoked by uid 0); 19 Sep 2015 12:07:44 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 19 Sep 2015 12:07:44 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id K67a1r00E2UdiVW0167dXC; Sat, 19 Sep 2015 12:07:43 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=ff-B7xzCdYMA:10 a=vaJtXVxTAAAA:8 a=IP1sjkWvd51f_uKrGBwA:9 Original-Received: from [76.218.37.33] (port=56804 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZdGvX-0006UK-94 for emacs-devel@gnu.org; Sat, 19 Sep 2015 06:07:35 -0600 In-Reply-To: <55FCA78B.3090803@yandex.ru> (Dmitry Gutov's message of "Sat, 19 Sep 2015 03:08:43 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.38.55 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:190097 Archived-At: Dmitry Gutov writes: > On 09/18/2015 08:14 PM, Stephen Leake wrote: > >> However, if the C include path is not purely recursive (which is >> likely), > > What is this guessing? I'm pretty sure it *is* "purely recursive", and > if not, please quote some documentation. "purely recursive" means no element of the path is a subdirectory of another element. It is quite possible for a project to have an include path like "root/include/dir1 root/include/dir1/dir2". >> then a purely recursive project-search-path will not be a >> superset, and this will fail (so it will fail with all of the current >> implementations of project-search-path). > > 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. 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. >> 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. > Please, let's cease the flat-search-path > discussion until we encounter a use case that's *really* hard to > handle without it. We already have, at least twice. But you refuse to listen, so yes, I'll stop trying. > 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. >> But the API is the interface between the clients and the backend; it >> would be much better to have clearer semantics, and options in the API >> to choose among the possible semantics. That way client code can be >> written that is truly independent of the project backends, and new >> backends won't break existing client code. > > 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. >> On the other hand, if we define project-search-path to return >> mixed-recursive (to match load-path or C include exactly), some client >> functions may be able to use it as is (they will have to make >> assumptions about what the backend is including). > > 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; I'm glad you agree. So why do you refuse to fix the documentation to be clear? >> We should start a file that documents the use cases we've discussed, so >> we don't forget them. > > Any suggestions for the collaboration platform? savannah Emacs git. -- -- Stephe