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: find-file-project Date: Thu, 17 Sep 2015 20:15:55 +0300 Message-ID: <55FAF54B.2030306@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> 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 1442510196 14895 80.91.229.3 (17 Sep 2015 17:16:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Sep 2015 17:16:36 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 17 19:16:31 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 1ZccnO-00040Y-31 for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 19:16:30 +0200 Original-Received: from localhost ([::1]:60188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZccnN-0007ha-PC for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 13:16:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZccnK-0007gr-NZ for emacs-devel@gnu.org; Thu, 17 Sep 2015 13:16:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZccnF-0004lG-KD for emacs-devel@gnu.org; Thu, 17 Sep 2015 13:16:26 -0400 Original-Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:35349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZccnF-0004f6-1G for emacs-devel@gnu.org; Thu, 17 Sep 2015 13:16:21 -0400 Original-Received: by wicge5 with SMTP id ge5so85091wic.0 for ; Thu, 17 Sep 2015 10:16:19 -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=Wi5a3m+Q7L5U8gJREBdd0m2jfDpzDVHHDt1Hbj+PXCw=; b=FwygRhADm/P7gzJ1e/TWIRP9yFjApt7Yqdln9RFVpY6islNDeVsSV9ukNanuPZGgFl k90v7dIl7wdFGFkuTCvwE312xIsOw2qkWpchxC4z3whY4Z5hvFwTZxY0cjRrG4a3DylI xjSxRB63FXH0AHPMcfziHV6vHsYqYoSYdNAKE0Ec5zbNAcRem2hGWx1ib1tNnVTQSvQ4 uftoZOtPyM6YLiCtd9m78vuVi1iec99hZS/xu9HNoYNqLG/qpOnjDf5uWtQMNf+R4sf4 pj/o3vai+vO7mbzBQV9FlBW0dm5PrLXhnJivG8lQVBR6WaXmJQm+OyBlklH6eyV2EpTd dmFA== X-Received: by 10.194.87.102 with SMTP id w6mr352200wjz.111.1442510179222; Thu, 17 Sep 2015 10:16:19 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id f17sm4416849wjn.38.2015.09.17.10.16.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Sep 2015 10:16:17 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86io7az4h3.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::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:190047 Archived-At: On 09/16/2015 07:58 PM, Stephen Leake wrote: >> It's not an Ada project. > > That's not a useful definition, and therefore not helpful in moving this > discussion towards closure. It's fairly workable, though, as I think we've established. We could call a project "flat" if, to create a source file in a new directory to the program, it's always necessary to add the new directory to a build file as well, or to some "directory paths" variable in the program's environment. That doesn't hold true for Emacs Lisp because we can add a file in a foo/bar, when only foo is in load-path, and then (require 'foo/bar) somewhere. By that measure, many Makefile-based projects could be called flat. So if we take just the part of Emacs written in C, if we add a new dir under src/, we'll have to modify Makefile with its settings. But no one really expects to ever have directories under src/ containing irrelevant files. And since we want to be able to visit src/bitmaps/* anyway (don't we?), we might as well treat src/ in a recursive fashion anyway. So I rather call a project "flat" if, in addition to the condition above, treating its directory list in a recursive fashion leads to results surprising to the user. >> 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? 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. So maybe a better approach is to allow project-search-path to include both "emacs/lisp" and "emacs/lisp/progmodes", and either ask callers to use project-prune-directories as needed, or provide an accessor that returns the path already pruned (project-search-path-roots?). > 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. project-prune-directories is a fairly quick function. Compared to a serious operation like listing files, it has no performance hit. (project-prune-directories load-path) takes 2ms here. What's so complicated? > 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. Whether I justify it or not, semantic/symref/cscope.el isn't going anywhere. *And* it's even more useful in other languages, like Ruby or Java. >> 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. In theory, probably. But the format of "flat" ignores you've proposed is less powerful than the current project-ignores. Or is project-ignore-files-globs supposed to contain items like "foo/*.c"? Or "foo/*/", or "foo/*/bar"? > 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. I don't think we really can avoid that. Your definition of the Elisp project will fail in some project we don't know about that also uses nesting and the format (require 'foo/bar/tee). > Whether that additional information is specified as "extra includes" or > "extra ignores" is a secondary issue. One also has to look at the actual language they're working with. > 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. And now you've hardcoded the same information in the project definition. Which will work most of the time, and then it'll fail for someone, for the reason described above. You could argue that "most of the time" is good enough, but note that the cogre problem you're trying to solve is pretty niche as well. I may never encounter any similar problems with Elisp. And adding a single ignore is pretty easy.