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: project.el semantics Date: Fri, 18 Sep 2015 12:14:41 -0500 Message-ID: <86pp1fwsxq.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442596532 24008 80.91.229.3 (18 Sep 2015 17:15:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Sep 2015 17:15:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 18 19:15:21 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 1ZczFo-0000Cx-7x for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2015 19:15:20 +0200 Original-Received: from localhost ([::1]:40714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZczFn-0005R0-IC for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2015 13:15:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZczFZ-0005NG-5B for emacs-devel@gnu.org; Fri, 18 Sep 2015 13:15:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZczFV-0003HO-S1 for emacs-devel@gnu.org; Fri, 18 Sep 2015 13:15:05 -0400 Original-Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:59139) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZczFV-0003Ej-Lo for emacs-devel@gnu.org; Fri, 18 Sep 2015 13:15:01 -0400 Original-Received: (qmail 24862 invoked by uid 0); 18 Sep 2015 17:14:57 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 18 Sep 2015 17:14:57 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id JnEn1r00V2UdiVW01nEqym; Fri, 18 Sep 2015 17:14:55 -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=kPtsFsWK_ZM4OQMu1aMA:9 a=MV5d6BvmsdwnqNvH:21 a=c30FVtaV0bkG9EW5:21 Original-Received: from [76.218.37.33] (port=65154 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZczFI-0004s9-4F for emacs-devel@gnu.org; Fri, 18 Sep 2015 11:14:48 -0600 In-Reply-To: <55FAF54B.2030306@yandex.ru> (Dmitry Gutov's message of "Thu, 17 Sep 2015 20:15:55 +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: 69.89.20.122 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:190061 Archived-At: Dmitry Gutov writes: > Currently, the default implementation of project-search-path calls > project-prune-directories. We could require it of all implementations, > so that there's no duplication of this kind. > > But then we won't be able to search for "qualified file names", like > "semantic/symref/cscope.el" (or would do it less accurately). Which > might be important in "jump to an import" usages. Not in Elisp (we > have a better implementation of that already), but in other languages. I'm guessing you are talking about something like a new function project-find-file-at-point that does the following: In a C file, if point is in an #include line, goto the beginning of a buffer containing the corresponding file. And similarly for other languages. In that case, the string in the #include could be something like "dir1/dir2/file1.h", or just "file2.h". If project-search-path is a superset of the C include path, we can iterate thru project-search-path, checking if (expand-file-name include-string dir) exists. However, if the C include path is not purely recursive (which is likely), 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). That's an argument for providing project-flat-search-path (overkill for this use case, but not harmfull), or project-c-include-search-path (precisely what this use case wants), or an argument to project-search-path telling it what sort of path to return. On the other hand, find-file-in-project and xref-search-regexp want purely recursive search paths. EDE defines at least two kinds of paths; include and link, which have different content. Different use cases have different requirements for the semantics of "search path". It will not be possible for a single function to meet all the required semantics. You suggest that we should define project-search-path loosely ("let the backend do whatever it wants"), and let the client code cope ("just call project-prune-directories"). 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. I believe all the use cases we've discussed so far can be met with reasonable efficency by providing both purely recursive and purely flat search paths. 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). Those that want pure recursive can call project-prune-directories on the result, and those that want flat can call project-recursive-ignores-to-flat. We should start a file that documents the use cases we've discussed, so we don't forget them. -- -- Stephe