From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: find-file-project Date: Tue, 19 Jan 2016 09:20:07 -0500 Message-ID: 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> <568C6DE5.8040201@yandex.ru> <568F1327.30905@yandex.ru> <569DD470.2060603@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1453213226 17298 80.91.229.3 (19 Jan 2016 14:20:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 14:20:26 +0000 (UTC) Cc: Stephen Leake , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 19 15:20:17 2016 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 1aLX8q-00015g-HK for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 15:20:16 +0100 Original-Received: from localhost ([::1]:37260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLX8p-00018Q-Rd for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 09:20:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLX8l-000186-V8 for emacs-devel@gnu.org; Tue, 19 Jan 2016 09:20:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLX8h-0007Sf-Qv for emacs-devel@gnu.org; Tue, 19 Jan 2016 09:20:11 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:17731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLX8h-0007SZ-MB for emacs-devel@gnu.org; Tue, 19 Jan 2016 09:20:07 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2FgA731xV/++PWxdcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEGAQEBAR6LOoUFB4QtBYtEbIQEjmOGaYsrg1kjggkdgXAggngBAQE X-IPAS-Result: A0A2FgA731xV/++PWxdcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEGAQEBAR6LOoUFB4QtBYtEbIQEjmOGaYsrg1kjggkdgXAggngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="190273394" Original-Received: from 23-91-143-239.cpe.pppoe.ca (HELO pastel.home) ([23.91.143.239]) by ironport2-out.teksavvy.com with ESMTP; 19 Jan 2016 09:20:07 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 07CEE5FF67; Tue, 19 Jan 2016 09:20:07 -0500 (EST) In-Reply-To: <569DD470.2060603@yandex.ru> (Dmitry Gutov's message of "Tue, 19 Jan 2016 09:15:12 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:198355 Archived-At: >> I'm not sure if you'd count filecache.el as "goes through >> read-file-name", but it seems relevant. > Indeed, it does seem relevant. But it doesn't define a completion table in > the standard way, so the question is moot. Ah, indeed, I have a local hack which turns it into a "standard completion table" but I never pushed it (and I'm not sure it should be either, because it's not very pretty: the behavior doesn't fit very well). > It's also one of the blockers for deprecating company-mode's > own backends. [ Side note: I recently changed nxml-mode to provide a proper capf, so it now "works" with company-mode, but company mode usually kicks in too late in my opinion. If you have time to spare, I'd appreciate if you could try to fine-tune it a bit. ] >> IOW instead of providing ad-hoc implementations for try-completion, >> all-completions, completion-boundaries, etc... you'd provide ad-hoc >> implementations of minibuffer-try-completion and >> minibuffer-all-completions, which have the advantage of allowing more >> flexibility in its output (e.g. the input doesn't need to be a prefix >> of the output). > I think you mean completion-try-completion and > completion-all-completions. Right. > How will this happen? Will these functions become generics? I was thinking of adding a new method to completion tables (beside the existing try, all, test, boundaries, and metadata), but maybe making them generics would work as well. Actually, all the completion-table methods could be turned into generics, but that requires figuring out on what to dispatch since currently all completion tables are either functions, lists, arrays or hash-tables and the "new table types" are sub-cases of function. > It would be great if you could file a bug and describe your current views on > this subject there, so it's not buried in this discussion. Done, Stefan