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: find-file-project Date: Wed, 16 Sep 2015 11:58:00 -0500 Message-ID: <86io7az4h3.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442422732 7468 80.91.229.3 (16 Sep 2015 16:58:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 16:58:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 18:58:41 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 1ZcG2Z-0006N8-80 for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 18:58:39 +0200 Original-Received: from localhost ([::1]:52035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcG2Y-0003ur-F2 for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 12:58:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcG2K-0003ug-2G for emacs-devel@gnu.org; Wed, 16 Sep 2015 12:58:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcG2E-0006NT-A8 for emacs-devel@gnu.org; Wed, 16 Sep 2015 12:58:23 -0400 Original-Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:52776) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZcG2E-0006N3-36 for emacs-devel@gnu.org; Wed, 16 Sep 2015 12:58:18 -0400 Original-Received: (qmail 25046 invoked by uid 0); 16 Sep 2015 16:58:13 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 16 Sep 2015 16:58:13 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id Hyy41r00o2UdiVW01yy7Pn; Wed, 16 Sep 2015 16:58:11 -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=axSj6shvbS6rkGCorqwA:9 Original-Received: from [76.218.37.33] (port=56848 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcG21-0000QX-6W for emacs-devel@gnu.org; Wed, 16 Sep 2015 10:58:05 -0600 In-Reply-To: <55F98538.7040700@yandex.ru> (Dmitry Gutov's message of "Wed, 16 Sep 2015 18:05:28 +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.226 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:190027 Archived-At: Dmitry Gutov writes: > On 09/16/2015 05:13 PM, Stephen Leake wrote: > >>>> And this is ridiculous. Emacs obviously isn't a "flat" project. >>> >>> I don't know what you mean by "a flat project". > > It's not an Ada project. That's not a useful definition, and therefore not helpful in moving this discussion towards closure. >>> load-path is neither purely flat (cedet requires recursion) nor purely >>> recursive (it has both emacs/lisp and emacs/lisp/progmodes etc). So it >>> has to be converted one way or another. > > "emacs/lisp and emacs/lisp/progmodes" is not a good counter-argument. > > search-path may have entries where one is a subdirectory of another, > but each such entry is "recursive" anyway (we have to consider all > files inside each respective tree). That's clearly suboptimal; the subdirectory will be processed twice in every use of project-search-path. Why would that ever be a good idea? project-prune-directories optimizes that usage, so that project-seach-path is purely recursive; I assume that's why it's there. project-recursive-ignores-to-flat does the same conversion, more accurately (it also produces the ignores list). > When search path used for file traversal, the caller will simply have > to filter out the entries that are redundant for its purposes. It clearly complicates completion; we have to delete lots of actual duplicates, rather than only worrying about files in different directories having the same name. When would such a definition of project-search-path actually be useful? You are going a long way merely to justify calling "load-path" recursive. >> And the user has to provide additional information as to what parts are >> flat vs recursive, for the conversion to be done properly. > > I don't see that. If you need this complexity, just use the > "recursive" format (it's more powerful), It is not "more powerful"; we have already agreed that one format can be converted accurately to the other; the code in the patch implements those conversions. You are missing my main point; the user must specify information in addition to "load-path" in order to determine the correct search path for an elisp project. Whether that additional information is specified as "extra includes" or "extra ignores" is a secondary issue. >> For example, SourceForge CEDET contains the "cogre" directory under >> "cedet". Since that is not part of Emacs core yet, if I'm testing >> SourceForge Emacs prior to a merge with Emacs core, it is not >> appropriate to include "cogre" in the project search path. > > Well, ignore it, then. Yes, that is the user intent. The question is, how is the user supposed to specify that intent to the elisp project? "load-path" alone does not state whether it should be ignored; the user must provide additional information. -- -- Stephe