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 08:31:42 -0500 Message-ID: <867fnq1oe9.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <55F8F2FA.6060902@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442410342 19984 80.91.229.3 (16 Sep 2015 13:32:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 13:32:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 15:32: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 1ZcCoj-0007PE-AS for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 15:32:09 +0200 Original-Received: from localhost ([::1]:50804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCoi-0002M3-LE for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 09:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCoe-0002Lp-IO for emacs-devel@gnu.org; Wed, 16 Sep 2015 09:32:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcCoY-0000Ri-GQ for emacs-devel@gnu.org; Wed, 16 Sep 2015 09:32:04 -0400 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:56222) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZcCoY-0000R2-9o for emacs-devel@gnu.org; Wed, 16 Sep 2015 09:31:58 -0400 Original-Received: (qmail 28474 invoked by uid 0); 16 Sep 2015 13:31:54 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 16 Sep 2015 13:31:54 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id HpXr1r0052UdiVW01pXuvF; Wed, 16 Sep 2015 07:31:54 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC 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=21HoJyXbeE1MBnhbv9kA:9 Original-Received: from [76.218.37.33] (port=55354 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcCoO-0007YS-9W for emacs-devel@gnu.org; Wed, 16 Sep 2015 07:31:51 -0600 In-Reply-To: <55F8F2FA.6060902@yandex.ru> (Dmitry Gutov's message of "Wed, 16 Sep 2015 07:41:30 +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: 67.222.33.93 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:190008 Archived-At: Dmitry Gutov writes: > On 09/16/2015 05:49 AM, Stephen Leake wrote: > >> Only code that needs flat paths uses them. As we discussed earlier, we >> can either compute the flat path, and do completion on it, or compute >> the flat path while doing completion. > > If you absolutely need flat paths for completion here, just having the > function that do one-way conversion should suffice. There's no need > for project-flat-to-recursive-ignores, for instance. I found it convenient for building a project object, and for testing. But it is otherwise not used in this patch. >>> The user could input a base file name, if they like, and TAB would >>> expand it to one of the relative paths if it's unique, or allow them >>> to input a directory. You won't need any other uniquification then. >> >> That requires the user to know what directory the file is in, as >> find-file completion does now. > > It doesn't - you complete using the files list you've collected during > the initial walk, and you match the typed file name against it. > There's no reason to require that the input matches the beginning of > the string. Except that 'completing-read' does require exactly that. I did try to prepend directories for uniquification; it doesn't work. Or at least it would require major surgery on completing-read to make it work. >> Using a flat path avoids that. I find it quite useful to just type >> "locate", and immediately see that there are two choices, one of which I >> was unaware of. > > On the other hand, if I understand it right, I can't type "test unit > foo", to see the unit test for foo. It's not google search. Can you be more specific? What is the file name you are trying to complete to? One thing it should handle but doesn't yet; when presented with: foo.el foo.el foo.el The user should be able to type > On the other hand, what you are describing is pretty much what >> find-file-project does. Have you tried it? > > Not yet. I will, when you push it to the feature branch. Ok, I'll do that. >>> Maybe call it find-file-in-project? >> >> That does sound better. > > Or just call the command project-find-file. It's inside project.el, > after all. There's already a project-find-file. There are two similarly named functions; one interactive, the other dispatching. EDE uses -impl suffix for the latter; that would work here. >>>> The patch also adds small projects for elisp and global, to show that >>>> this approach works for multiple backends. >>> >>> I don't see the elisp backend. >> >> Oops; that got left out of the patch. This code is supposed to be in >> project.el: > > I see, thanks. > >> (defvar project-emacs >> (let ((cedet-root (file-name-directory (locate-file "cedet.el" load-path)))) >> (project-elisp-make >> (project-recursive-ignores-to-flat >> (list >> (concat cedet-root "ede") >> (concat cedet-root "semantic") >> (concat cedet-root "srecode")) >> nil) >> ))) > > And this is ridiculous. Emacs obviously isn't a "flat" project. I don't know what you mean by "a flat project". 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. I did try to use the recursive approach; this seemed simpler. I'll use the recursive approach in the feature branch, for a true comparison. >> More importantly, the result of the completion is treated differently; the >> default instance calls locate-file after rearranging the uniquification, >> while the global instance calls ceded-gnu-global-call. > > Why? If we've identified the requested file, let's just open it. `completing-read' does _not_ return an absolute or unique path. See below. >> A better way to accomplish this would be to somehow encode the full >> directory path in the completion result, but I didn't find a way to do >> that. In particular, text properties are not returned from completion. > > This seems to be a good argument against using base file names, and in > favor of using full relative paths against project roots, combined > with abbreviated roots. That would add significant clutter to the UI when filenames collide; you often don't need the full path to a root to distinguish them. And in the global case, the elisp code has no idea what path global is using; it must always call global to get an absolute path. It would make sense to modify completing-read to be able to return meta-information with the completion. I looked at that briefly, and I have no idea how to go about it. >> I guess you are asking for some rationale. This code allows converting >> between the two equivalent representations of search paths; >> recursive/ignores and flat. As we have discussed before, there are cases >> where both of these conversions are useful. > > Not really. You don't need the ability to convert from flat paths to > recursive if the project API consistently uses the "recursive" format. > All data is already in it. You keep ignoring the fact that in some use cases, the available project path information is already flat, and has to be converted to recursive/ignores. I presented the AdaCore gpr file example. In addition, a mix of flat and recursive/ignore is convenient for users constructing a path. This does need some unit tests for the conversion functions. -- -- Stephe