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 21:09:01 +0300 Message-ID: <55FB01BD.1070909@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> <55F9A13A.3070101@yandex.ru> 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 1442513384 2638 80.91.229.3 (17 Sep 2015 18:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Sep 2015 18:09:44 +0000 (UTC) Cc: Stephen Leake , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 17 20:09:39 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 1Zcdcn-0003R5-KY for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 20:09:37 +0200 Original-Received: from localhost ([::1]:60425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zcdcn-0000oB-9I for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 14:09:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zcdce-0000nr-Hf for emacs-devel@gnu.org; Thu, 17 Sep 2015 14:09:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zcdcb-0006ol-AV for emacs-devel@gnu.org; Thu, 17 Sep 2015 14:09:28 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:35402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zcdcb-0006oT-2x for emacs-devel@gnu.org; Thu, 17 Sep 2015 14:09:25 -0400 Original-Received: by wicge5 with SMTP id ge5so1902548wic.0 for ; Thu, 17 Sep 2015 11:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=gBS2Pz/pwktWqq/ev6LBTGTYthbyuNCClupSfgEcYhQ=; b=Y4A6CA/5YHQkcxeIthE5chDshVPxAe94eLe9KGPxdoPp6ijCgOmQL57uSLNVzZcM+7 jseJnKVIIsemE50B30H/hgUDqF92Y4ZwxGgA9uhuEmkzTR7ftKbGOPcZhyvJTQpSKU6q 3l5NJAtf734Drbh+aSfmWLiIrRXWMx48gf5Arqkv0zdWqgplIWqiUhXs3kAYjXMlrwn4 XsiiAm3el3QffrWHwRPr060VwF3BAbuMnSIMlbxY0/R64movqqmVJCdd9vm6TD8jtos4 F9rSPJsObE0VSacJJjLezrPuMAKGVVKwhZujvD9YL4Bxvy78nEAoCLVm/8c3opbk0HTP 9b0A== X-Received: by 10.194.84.129 with SMTP id z1mr935494wjy.17.1442513364154; Thu, 17 Sep 2015 11:09:24 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id go2sm11321556wib.20.2015.09.17.11.09.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Sep 2015 11:09:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b 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:190050 Archived-At: On 09/17/2015 04:26 AM, Stefan Monnier wrote: > Indeed, the kind of completions you're suggesting will require > such tweaks. It brings up a related issue: `category' is a metadata element. Do we really want to require every project-file-completion-table implementation to include that piece of metadata? Being able to assign it to the returned table in find-file-in-project would be handy. >> You'll be able input "/file", and it'll match "foo/bar/file.el". > > I don't see how `partial-completion' would do that. The same way as "-firefox" expands to "browse-url-firefox"? It doesn't work with 'find-file', but maybe only because completion-file-name-table doesn't interpret "//" as "/**/". It doesn't interpret "/**/" properly either (only treats it as "/*/"). > [ I did have some earlier version of partial completion match "**/file" > to "foo/bar/file.el", but the current code doesn't have that, and even > less so without a "**". ] Why not? Anyway, I was talking about implementing a new completion table, nor necessarily reusing completion-file-name-table. > Suggestions: > > - combine substring and partial-completion, > e.g. "a*l/b" can find "cable/rob.el". If globs weren't trivial to implement here, honestly, I would leave the support for them altogether. > - foo/bar should be able to find "tv/football/field/barberis.txt". > I.e. like `partial-completion' but if "foo" doesn't match anything, > look for it recursively. Yes. > - Same thing but where the order doesn't matter: bar/foo should also > find "tv/football/field/barberis.txt". This one should probably > automatically recurse, even if there is a match in the current directory. I rather leave that for a separate style, too permissive for my taste. > - maybe "bar/foo" should also find "tv/myfootball/field/umbertobarberis.txt". Why not. Although maybe I'd rather only match 'foo/bar', but not 'bar/foo'. We might want a knob here.