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: Sat, 19 Sep 2015 02:41:25 +0300 Message-ID: <55FCA125.4090204@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> <55FB01BD.1070909@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 1442619724 19944 80.91.229.3 (18 Sep 2015 23:42:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Sep 2015 23:42:04 +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 Sat Sep 19 01:42:00 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 1Zd5Hy-0001IM-KD for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 01:41:58 +0200 Original-Received: from localhost ([::1]:42506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd5Hy-0005TO-00 for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2015 19:41:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd5Hu-0005TG-Gk for emacs-devel@gnu.org; Fri, 18 Sep 2015 19:41:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zd5Hq-0000iY-GS for emacs-devel@gnu.org; Fri, 18 Sep 2015 19:41:54 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:37652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd5Hq-0000iU-AJ for emacs-devel@gnu.org; Fri, 18 Sep 2015 19:41:50 -0400 Original-Received: by wicfx3 with SMTP id fx3so48159762wic.0 for ; Fri, 18 Sep 2015 16:41:49 -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=Laxb8rol0Nzy7NLC3jplR+1SHs3SzgxuGYcASSC+s/0=; b=j6g6lU2+T522rfRpa45CWVZUEFydp/3NwNIkHc5UuNvnUGyv2qsIj8qlAiho9hWblq S96P8MkIB8ChqY8uSvJ/+i3TzU2CqbVHKsdbBkAbOOz4PiibAc7UT2byTKiU/ig/m+Ub 5KtwzWj4Q1FeEkb9IF++z7/ycejr3ohT1UdN2TW9nxtefhWg8i8COZ0ilKBfeXPrICEM KXiEUaPWTQzET2zr5y5La5D03IBeQiHzryOOIhY9E6cHqMzyml2lAoodpLP/+qhGa3HD XsZjbs9nBPicaR4XKafOEGHUMFWVIEbC/PeMRsMVqTG/MAy8FLZixx4UhNjomtTS23df SV3Q== X-Received: by 10.180.89.101 with SMTP id bn5mr707223wib.20.1442619709302; Fri, 18 Sep 2015 16:41:49 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id gc8sm523600wib.2.2015.09.18.16.41.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 16:41:48 -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::236 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:190067 Archived-At: On 09/18/2015 08:07 PM, Stefan Monnier wrote: > Of course, project-find-file could wrap the backend's completion table > so as to add its own `category' info to the meatadata, but > it's cumbersome. Indeed. > We should try and unify the metadata returned by the completion-tables > and the metadata returned by the completion-at-point-functions (or > provided via completion-extra-properties). Yup. We should probably do that sooner rather than later. > Ah, I see. But that means all the files are returned as one flat list > (without using completion-boundaries). Might be a good idea. Ouch. That means I really misunderstand how completion-boundaries work. >>> [ 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? > > Couldn't find that 25th hour! Well, I meant that if earlier code already did it, you had to remove it. But I guess there was more work to be done, to make it good enough for public.