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, 20 Jan 2016 03:51:02 +0300 Message-ID: <569ED9F6.3050003@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> <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; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453251082 30162 80.91.229.3 (20 Jan 2016 00:51:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 00:51:22 +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 Wed Jan 20 01:51:15 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 1aLgzT-0007mJ-6Z for ged-emacs-devel@m.gmane.org; Wed, 20 Jan 2016 01:51:15 +0100 Original-Received: from localhost ([::1]:39765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLgzS-0005Zn-M3 for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 19:51:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLgzO-0005ZV-MN for emacs-devel@gnu.org; Tue, 19 Jan 2016 19:51:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLgzJ-00075J-MJ for emacs-devel@gnu.org; Tue, 19 Jan 2016 19:51:10 -0500 Original-Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]:35786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLgzJ-00075E-9y for emacs-devel@gnu.org; Tue, 19 Jan 2016 19:51:05 -0500 Original-Received: by mail-lf0-x22b.google.com with SMTP id c192so349806181lfe.2 for ; Tue, 19 Jan 2016 16:51:05 -0800 (PST) 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=JsDBWZSr9fBZ1CtDac2i1edByovFuM97C84BCPD9oGE=; b=KQlzgFXVxuFNik/a430Hdn8iFlCiyLl58HOIeo2VOnm3BnG2ak77wzlGLwmZFlhnXh yq5Di9Cgg+O1Da9hzsNRK7wRicWImxRtSW7rKdJEYJMGwjJXpDIjM7+s5c9KoV+noNVe Z1Ix5LhMMErHA2pGPDqNEZnbHHHYp4uZaYVPGofv6ZfHq9BNuMBv8B4fBP6V2csnOFUT y3zKrosMaBlGpFOJuwyxS8azfTX1kTBWEK3bs6uPCNX2gDfBu2sZZbzU3HoIojf/MHvN JjC2wLPcHmvO7maF5aUvDBqkaqtNANFt/SrYVviYly1N1+WUWDTGuH1Uo6uqD0RoTHUm kofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=JsDBWZSr9fBZ1CtDac2i1edByovFuM97C84BCPD9oGE=; b=XUAlMrLFeXsq4AJCIqOVsKcd35PTQ3rhmFrcl8gw98kEn+0+J8CVb19+kOcha7pKCl XqAuNbY72DWTOqiF9YtYrGFAEXM1YQ5XPnZW4VlSouo1StfHS+qKYtUxo6WIzvgnh+7w lZSTbJy+jdcSqCj67hwH7Naz3Psj01P073EnuVGR+6/pYsHfkmbYpmJsiuKNYcicFTzK Ir+ermhFq1twi3AnVDIi5JKR6vSLpZ/LJGBAnAj8TMKee38+LdTr8G9K71p/GwXe4jfa KZD9vIL+LB8MbPE3UNsaQjj7Conmy1y/QgvEy8d5QGaxuSp04npHMTtN7sFrQU6EOuxC h7Cg== X-Gm-Message-State: ALoCoQkzXtCAEq22kk7M1soxXJsgZnvMJzUVlUD7+6OUWbXVRg/M4VvF4iRdnQlBnUTGqsTQlUpz46D0hSrTYEd2AYUsNpE2rQ== X-Received: by 10.25.169.74 with SMTP id s71mr10506090lfe.128.1453251064317; Tue, 19 Jan 2016 16:51:04 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id 99sm4428363lfp.30.2016.01.19.16.51.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 16:51:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::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:198404 Archived-At: On 01/19/2016 05:20 PM, Stefan Monnier wrote: > 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). Standard completion doesn't fit? And simply iterating between the suggestions fits it better? What's the main difference between the list provided by filecache.el and the list of files used by project-find-file? >> 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. ] Too late how? - If you have to wait too long after typing a few chars, you can lower company-idle-delay. - If you have to type too many chars for completion to kick in, lower company-minimum-prefix-length? Alternatively, a "native" company backend can return a cons value with a fake "length" to compare against the latter variable's value (or t, to mean that the check will succeed). I've recently accepted a patch adding a similar capability to company-capf, on github: https://github.com/company-mode/company-mode/pull/450. If nxml-mode completion always uses a limited set of tags/attributes/values, maybe it could always return t as the "prefix length". (I don't really know if that's true or not.) > 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. It seems to me the functional completion tables could be complex enough already. > 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. lists/arrays/hash-tables could be handled by the default methods. Maybe functions, too (or use a different method for them, with a specializer using functionp?). "New" completion tables could be conses tag+function, or cl-structs. But that's a bit of a separate concern: since completion-try-completion and completion-all-completions are on a higher level, I think *they* could be generics, whereas the all-completions/etc could stay as they are. >> 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, Thank you. Although you've omitted the part about generics, so I'm unsure where to continue that part of the discussion.