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:45:26 +0300 Message-ID: <55FAFC36.5010506@yandex.ru> 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> <86pp1ixem2.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 1442511972 11768 80.91.229.3 (17 Sep 2015 17:46:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Sep 2015 17:46:12 +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:46:11 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 1ZcdG6-0003K2-3Y for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 19:46:10 +0200 Original-Received: from localhost ([::1]:60336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcdG5-0002y1-6J for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 13:46:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcdFs-0002xl-RM for emacs-devel@gnu.org; Thu, 17 Sep 2015 13:45:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcdFn-0001lN-Qw for emacs-devel@gnu.org; Thu, 17 Sep 2015 13:45:56 -0400 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:35832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcdFm-0001lC-Ig for emacs-devel@gnu.org; Thu, 17 Sep 2015 13:45:51 -0400 Original-Received: by wicge5 with SMTP id ge5so1097590wic.0 for ; Thu, 17 Sep 2015 10:45:48 -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=7vm2xOdsGD2QiwEi2xw3eXtAjq2DY3udPlReiirylNc=; b=CFl0e/l2Tj5taU0TWEv6PX0nEJt1LWuHdZ49PDROfUJn9HyjVfaU7PDg18jPjO8SPD 18CatxoKW6H5MvdYkJ0aGYK8GrzufQ1tCTGAVp8GZso+m4QrBRe5mwpkYO8rJSqH5Lxr c7kf2W5Qr16gGPxsMc118Y2sZDAyrAlvPW9Qafj+L4s1BOtvXFu+qbM2/QQVmJV/JUlx TRRn78h9N0FlyZ6xlry2V8D5at6VLRs1QWbOlmo3gFa/f+xf0IcT9iJ0/J+dVuEfyIE3 2wVDwuECTZtaNYpLGuX7UU8GNM+nxY6H/M+8v8thtWrXUyN96dCnv5yZZhE78UlVUjK/ NAjg== X-Received: by 10.180.106.233 with SMTP id gx9mr10294343wib.32.1442511948603; Thu, 17 Sep 2015 10:45:48 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id pb4sm4561923wjb.8.2015.09.17.10.45.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Sep 2015 10:45:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86pp1ixem2.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::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:190048 Archived-At: On 09/17/2015 12:01 AM, Stephen Leake wrote: > That's what the "..." is supposed to mean. I guess I was not being > "really clear". Sorry. In see. In hindsight, it should've been obvious to me, though. > In the following, let's assume that "..." is "c:/project1". Ok. >> 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. You've asked about the difference between project-roots and project-search-path. Anyway, it's not too important 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? Sure. > Does this mean file name completion should search on project-roots, not > project-search-path, for this use case? Err, that looks like a non-sequitur to me. project-find-file should search in where it's defined to search (up to you). It just occurs to me that some users might expect it to only list files in the currently opened project(s), whereas other users would like to jump to system include files as well. > 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. It's kinda redundant, but as long we define project-search-path as a list of directories with *source* files, it may omit the root directories if they contain only, say, documentation. But we want xref-find-regexp to search in documentation as well. > 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 I don't see your point. Yes, ignores should be used, but only when there are ignores. "Flat" search path will have to use ignores as well ("dir3/dir31/*.dvi" is a good example). > project-ignores must return c:/project1/dir2/dir21/obj/ in this example. You can have it return the absolute files names, but it's quicker to relative, "rooted" ignores. > Sorry, I need "yes" or "no"; this either meets the spec (and intended > semantics) of project-ignores, or it doesn't. I would like to amend my answer: no, it's incorrect. (project-ignores ".../dir3") should return ignores relative to that directory. So "./dir3/dir31/*.dvi" would be "./dir31/*.dvi" instead. Or return absolute file names, they would work as well. >> 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". Aside from the detail above, yes. > Hmm. I had not considered that approach. It could well be that spawning > "find" is faster than iterating over the disk in elisp. It's been tried, and it's definitely faster, especially for larger projects. > However, I don't want to rely on "find.exe" on Windows boxes, so I'll > stick with an all elisp solution. I would urge you to reconsider: we assume the presence of 'find' already. M-x rgrep is probably the most common command that relies on it. Or M-x find-dired. > 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. Yes, if you insist on processing it in Lisp. >> Thank you. I was hoping you'd come to that conclusion. > > You could have been more constructive in getting there. If you mean the small jab about Ada, I grew impatient about having to reiterate what we've already established about Emacs Lisp. Sorry? Or do you mean something else? I've suggested to use completion-at-point from the outset.