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:41:34 -0500 Message-ID: <86mvwmz58h.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <86mvwn11u1.fsf@stephe-leake.org> <55F8E451.9080902@yandex.ru> <86bnd21q0r.fsf@stephe-leake.org> <55F97EA2.9000408@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442421740 23102 80.91.229.3 (16 Sep 2015 16:42:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 16:42:20 +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:42:08 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 1ZcFmW-0003Zm-AH for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 18:42:04 +0200 Original-Received: from localhost ([::1]:51966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcFmV-0007Q9-KH for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 12:42:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcFmS-0007Pv-EF for emacs-devel@gnu.org; Wed, 16 Sep 2015 12:42:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcFmN-0008EF-D5 for emacs-devel@gnu.org; Wed, 16 Sep 2015 12:42:00 -0400 Original-Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:48983) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZcFmN-0008D0-6L for emacs-devel@gnu.org; Wed, 16 Sep 2015 12:41:55 -0400 Original-Received: (qmail 21923 invoked by uid 0); 16 Sep 2015 16:41:52 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 16 Sep 2015 16:41:52 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id Hshj1r00p2UdiVW01shmUn; Wed, 16 Sep 2015 10:41:50 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ 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=v5rC3MM_3ATgYtab16AA:9 Original-Received: from [76.218.37.33] (port=56730 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcFmD-0004Tg-EZ for emacs-devel@gnu.org; Wed, 16 Sep 2015 10:41:45 -0600 In-Reply-To: <55F97EA2.9000408@yandex.ru> (Dmitry Gutov's message of "Wed, 16 Sep 2015 17:37:22 +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:190026 Archived-At: Dmitry Gutov writes: > On 09/16/2015 03:56 PM, Stephen Leake wrote: > >> One question; what does "To root an entry, start it with `./'. " mean? >> How does that affect the intended matching? > > That means that ./f* matches ./foo, but not ./bar/foo (these are paths > relative to the root). By "root" I guess you mean the argument "dir", since that is an element of the recursive project-search-path. To be very clear, suppose we have this directory structure: dir1/ dir11/ file1.el file1.elc dir2/ dir21/ obj/ Makefile foo.exe bar.exe test_1.text test_2.text dir22/ able.exe dir3/ dir31/ file3.texi file3.dvi file4.text project-search-path returns (".../dir1" ".../dir2" ".../dir3"); thus project-ignores is only called with one of these three values. (I'm ignoring project-roots, because I don't understand when it would be different from project-search-path). The user wants to ignore "*/*.elc", "*/*.dvi", "*/*.exe", "dir2/dir21/obj/*", "dir2/dir21/*.text", "dir3/dir31/*.dvi". So one implementation of project-ignores could be: (cond ((string-equal dir ".../dir1") '("*.elc" "*.dvi" "*.exe")) ((string-equal dir ".../dir2") '("*.elc" "*.dvi" "*.exe" "./dir2/dir21/obj/" "dir2/dir21/*.text")) ((string-equal dir ".../dir3") '("*.elc" "*.dvi" "*.exe" "./dir3/dir31/*.dvi")) ) A real project implementation would use an alist or hashmap. Then find-file-path-completion-table could take a recursive project-search-path as the "path" argument, and recurse thru the directory tree, calling project-ignores at each directory, with a parent directory from project-search-path as the argument, and comparing the path of each file - relative to the parent directory - to the glob patterns. For example, when processing dir2/dir21, it calls (project-ignores "dir2"), and compares "./dir2/dir21/obj/" to "dir2/dir21/obj", and "*.exe" to "dir2/dir21/foo.exe", both yeilding "ignore". Is that right? I gather this was designed to match the semantics of find? I don't see any uses of project-ignores in the current code, but it could be used with find-grep in a project-aware xref. Since the compare for directories is different from that for files, it would simplify the use of project-ignores (at least for this use case) if it was split into project-ignore-files and project-ignore-dirs. Or took an arg to specify that. But I'll use it as is, and see how much that would really gain. I was stuck on using a flat path for find-file-path-completion-table because I started out trying to reuse locate-file-completion-table. But now that I'm implementing the completion function from scratch, and it is reading the disk and ignoring some files anyway, it does make more sense start with a recursive path. -- -- Stephe