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: Wed, 16 Sep 2015 07:41:30 +0300 Message-ID: <55F8F2FA.6060902@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.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 1442378524 5700 80.91.229.3 (16 Sep 2015 04:42:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 04:42:04 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 06:42:04 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 1Zc4Xi-0004Pa-LV for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 06:42:02 +0200 Original-Received: from localhost ([::1]:47365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc4Xh-000437-T4 for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 00:42:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42585) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc4Xe-00042x-Hn for emacs-devel@gnu.org; Wed, 16 Sep 2015 00:41:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zc4XX-0005iW-E3 for emacs-devel@gnu.org; Wed, 16 Sep 2015 00:41:58 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:33828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc4XX-0005iO-4X for emacs-devel@gnu.org; Wed, 16 Sep 2015 00:41:51 -0400 Original-Received: by wicfx3 with SMTP id fx3so55149697wic.1 for ; Tue, 15 Sep 2015 21:41:50 -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=8J6bAeIdjbJ6KDPJSSNss95CBHftaPRwxL0D4Xie55c=; b=AENhT2l/+xc3YKJg+DoLef9gvPIkamnOn/+BesAfi9r4YR4AYpCRw+MJlbKMoZjgjL 6cju1EQgDn1doPFM6lZRcB0ziqkyGe8pyfPHkWhvA/X+sjSiich8inDx5I0JbikTt+1H Kq4eqGuLRIWgg/ZM7ieQnBNPlrTxz2diYJ/QvD0ATnf0H35ApERIjMODevAnDanES5Dt TSr9d6jb84H0WTsXsiW+HWqI3eEE0ewicjnRyPUhpt2cqmEVU5Vf2vr9dIUW86QKMsoF t7HYNZThe4zTCY0/4AANNyZuVTHS1fUWufsaSC8Ku9fH8K5uEcGiDIpvMtruTJu+6CZo KwXg== X-Received: by 10.180.106.196 with SMTP id gw4mr14852721wib.63.1442378510350; Tue, 15 Sep 2015 21:41:50 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id ex8sm2259923wib.14.2015.09.15.21.41.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 21:41:49 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86lhc73wog.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::233 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:189998 Archived-At: 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. > And as we also discussed earlier, for _some_ projects, flat paths _are_ > optimal. That just means that the respective backends will store user settings in a certain fashion. There's no need to add functional duplication to the project API. > What is the downside of a few dozen lines of code to support a few > projects? Implementation uncertainty and API complexity. >> Why not just implement completion on file paths relative to the >> project root? > > For Emacs elisp, there is no single root, except perhaps "/". That's a decent argument. But then, when there are several roots, you could uniquify just their names, and prepend them to file names. Your way may be better, but I'm not too sure yet. >> 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. > 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. > 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. >> 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. >>> 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. Just use the current format. > I've also implemented ede-find-file, which dispatches to the > semantic-symref global backend. Next patch. Is there a reason to keep the gtags backend, then? > I've already tested it. I guess if you mean if I want others to test it. Yes. > I was hoping this patch would be enough. It isn't. Sorry. >> I don't think each implementation should do its own completing-read. >> Rather, they should just return the completion table from a generic >> method. E.g. (cl-defmethod project-file-completion-table ...). > > For the default find-file-in-project, that would require computing the > flat path and the predicate on each use of the completion table. Why? The generic function could just as well return (completion-table-with-cache #'find-file-complete-global-table). > Other > instances might want to bind completion-ignore-case or > completion-regexp-list. completion-ignore-case is no business of theirs. Instead of completion-regexp-list, they can use a completion table with predicate. > 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. > I don't follow; the completion does not need to be sorted. This code is > dealing with the result of completion. I see. > 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. > It's on a par with the existing EDE "generic" projects for vc tools. And > with the existing project-vc. project-vc is an minimum-viable-product for those who don't bother configuring anything else. There's no reason to have many of them. > I don't follow; what file names are being shortened? On the contrary, > they are being lengthened, with enough directory names to make them unique. Either way, you're trying to same on typing during completion. completion-at-point helps with that as well. > 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.