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 16:01:57 -0500 Message-ID: <86pp1ixem2.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> <86mvwmz58h.fsf@stephe-leake.org> <55F9A5F8.1030505@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442437371 20220 80.91.229.3 (16 Sep 2015 21:02:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 21:02:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 23:02:40 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 1ZcJqh-0000hZ-NI for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 23:02:39 +0200 Original-Received: from localhost ([::1]:53498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcJqh-0000MM-BR for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 17:02:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcJqT-0008Qn-4T for emacs-devel@gnu.org; Wed, 16 Sep 2015 17:02:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcJqO-0003Go-0P for emacs-devel@gnu.org; Wed, 16 Sep 2015 17:02:25 -0400 Original-Received: from gproxy7-pub.mail.unifiedlayer.com ([70.40.196.235]:56027) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZcJqN-0003DW-Q6 for emacs-devel@gnu.org; Wed, 16 Sep 2015 17:02:19 -0400 Original-Received: (qmail 32270 invoked by uid 0); 16 Sep 2015 21:02:16 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 16 Sep 2015 21:02:16 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id J3251r0032UdiVW01328w6; Wed, 16 Sep 2015 21:02:15 -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=BCvJYKZiaQMY3mU3recA:9 Original-Received: from [76.218.37.33] (port=58936 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcJq9-0005oR-Qc for emacs-devel@gnu.org; Wed, 16 Sep 2015 15:02:06 -0600 In-Reply-To: <55F9A5F8.1030505@yandex.ru> (Dmitry Gutov's message of "Wed, 16 Sep 2015 20:25:12 +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: 70.40.196.235 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:190037 Archived-At: Dmitry Gutov writes: > On 09/16/2015 07:41 PM, Stephen Leake wrote: > >> By "root" I guess you mean the argument "dir", since that is an element >> of the recursive project-search-path. > > Yes. A root, or a search-path element. > >> project-search-path returns (".../dir1" ".../dir2" ".../dir3"); thus > > As documented, project-search-path should return absolute file names. That's what the "..." is supposed to mean. I guess I was not being "really clear". Sorry. In the following, let's assume that "..." is "c:/project1". >> 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). > > Indeed, the logic should be pretty similar. But the external > project-search-path entries usually doesn't have any ignored > directories, whereas there are often ignored dirs inside > project-roots, usually configured via .gitignore or the project file. You've lost me here. There is an ignored dir in this example; c:/project1/dir2/dir21/obj/. Is that supposed to be in the result of project-ignores or not? Does this mean file name completion should search on project-roots, not project-search-path, for this use case? xref-find-regexp searches on both, which is redundant. For example, for a file in Emacs core, using only project-try-vc in project-find-files, project-roots returns ("c:/Projects/emacs/master/"), and project-search-path includes that directory along with others. As we have discussed, in general a recursive path requires ignored directories in order to be accurate. So since project-search-path is recursive, it must always be used together with ignores; that means project-ignores must return c:/project1/dir2/dir21/obj/ in this example. >> 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")) >> >> ) > > I suppose. Sorry, I need "yes" or "no"; this either meets the spec (and intended semantics) of project-ignores, or it doesn't. > Or you could simply return the whole list each time, and > leave it to 'find' to apply the ignores appropriately. Not sure what > the performance hit will be. There might be false positives as well. I'm guessing this means "yes, it meets the intended semantics". I did say "one implementation could be". Optimization can be left for later, if performance is at all an issue. >> 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. > > I would just call 'find' for each "root" directory, pass it the > appropriate ignores each time, and then parse its output. Hmm. I had not considered that approach. It could well be that spawning "find" is faster than iterating over the disk in elisp. However, I don't want to rely on "find.exe" on Windows boxes, so I'll stick with an all elisp solution. >> 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? > > It could, though the paths will be absolute. The argument to project-ignores will be "c:/project1/dir2"; I got that wrong. I guess you are also saying that the elisp functions for getting a list of files in a directory will return absolute paths, so this will actually be comparing "./dir2/dir21/obj/" to "c:/project1/dir2/dir21/obj". Which can be accomplished by first expanding the glob pattern relative to the current root. That would be one way to implement it. >> 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. > > Well... an entry that doesn't end with a slash, in .gitignore, will > ignore both files and directories with that name. Ah, that is what the doc string says; I was misreading it. >> 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. > > Thank you. I was hoping you'd come to that conclusion. You could have been more constructive in getting there. -- -- Stephe