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 20:04:58 +0300 Message-ID: <55F9A13A.3070101@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <55F8F2FA.6060902@yandex.ru> <867fnq1oe9.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 1442423164 14374 80.91.229.3 (16 Sep 2015 17:06:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 17:06: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 19:05:57 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 1ZcG9d-0006Se-6q for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 19:05:57 +0200 Original-Received: from localhost ([::1]:52074 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcG9d-00073w-0H for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 13:05:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcG97-0006ya-P7 for emacs-devel@gnu.org; Wed, 16 Sep 2015 13:05:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcG91-0001Pz-Nm for emacs-devel@gnu.org; Wed, 16 Sep 2015 13:05:25 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:38310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcG91-0001PV-Eo for emacs-devel@gnu.org; Wed, 16 Sep 2015 13:05:19 -0400 Original-Received: by wiclk2 with SMTP id lk2so80190234wic.1 for ; Wed, 16 Sep 2015 10:05:18 -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=vTSpZoXgV4VtbSiowE49Q4iVQyMqJR0RyITzfz8Ldaw=; b=cQbszK6rRKSUO71qYvHcMQllHu/9UKZXAzEQhmRvUi96O8GwBQq0HPEHfTsBEPlJD3 fCFEFW5ihSbN4Az/dmchBbYKqBiV3ZpvcLyRpVHGxidkvK9DLC0+27wp/vreizeN9BOn 4aUZWd2Xi7usU0HydQAWgFCWKOAsZxMu89PriBg5/I3Sx2NI8oyzLsPMb1A48MqrGDXe PqJl++WuhSxpDExvj7dcsl6QIPSEivpJuF83ua/AW7p1AyLqaFsh7cs7L4iijqxTViUM dDIUg8N4gEMHzhgvnlixwpce3ASbEzPcxvxlCbo3GCu3emdOkPcQpcDMMPM0ZKt/yXqe Qxpw== X-Received: by 10.180.79.34 with SMTP id g2mr21370843wix.28.1442423118640; Wed, 16 Sep 2015 10:05:18 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id pg5sm27497013wjb.21.2015.09.16.10.05.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Sep 2015 10:05:17 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <867fnq1oe9.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:190031 Archived-At: On 09/16/2015 04:31 PM, Stephen Leake wrote: > I found it convenient for building a project object, and for testing. > But it is otherwise not used in this patch. Please build the project objects using the "recursive" approach. > 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. You might have to use a different `category' and set up a `completion-category-overrides' entry that would only use `partial-completion' as its style. You'll be able input "/file", and it'll match "foo/bar/file.el". The completion table will have to handle the `boundaries' action properly, though. Later, we can even add a new, more permissive style. We could use it in other places as well. >> 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. I'm sure you agree that web search is very handy. > Can you be more specific? What is the file name you are trying to > complete to? Suppose I have ./test/unit/foo_test.rb and ./test/functional/foo_test.rb. Typing 'unit/foo' or 'functional/foo' would return one or the other. Note that trying to uniquify the paths automatically might create abbreviations where the user would try to input a path segment fully (not in this example, though). > 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 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. If I'm not mistaken, project-find-file, as currently implemented, will go away after you use completion tables as described above. But if not, find-file-in-project is also an adequate name. >>> 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. Well, it could. I wonder if we shouldn't go at it this way: project-file-completion-table will return a table which returns absolute file (and directory) names. find-file-in-project calls completing-read with that table. However, we could have a completing-read-function (now, or add it at some later time) which would display completions is some abbreviated fashion (shortening the roots, basically). As a drawback - it might clash with completing-read-function already customized by the user. Not sure how to compose or prioritize them. Alternatively, find-file-in-project could wrap the returned completion table in some "abbreviating" one that abbreviates the project roots in file paths when displaying them (and possibly abbreviates some file name segments as well). Then, after the selection is made, find-file-in-project simply expands the root abbreviation. Or, if some segments can be abbreviated too, it polls the wrapping table to get the original file path (so the table should maintain some correspondence cache). Not sure if find-file-in-project should looks inside the whole search-path; if so, replace "project roots" with "search dirs" above. Yet another option is simply to make find-file-in-project search only within the current project root. >> 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. You probably mean "don't collide". Yes, there will be some visual overhead, but this approach is probably the most flexible WRT different project structures, and the user can understand easily what's required of them. Less so with foo.el 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. I don't understand. Can't Global return absolute file paths? > 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. It must be doable, but we can manage without 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. Maybe it has to, but not in the API. > In addition, a mix of flat and recursive/ignore is convenient for users > constructing a path. Please, let's avoid that kind of complexity in the API. The recursive format is more powerful, so we should use just it.