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 20:32:00 -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> <569ED9F6.3050003@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1453253545 767 80.91.229.3 (20 Jan 2016 01:32:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 01:32:25 +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 Wed Jan 20 02:32: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 1aLhd8-0006EQ-Ek for ged-emacs-devel@m.gmane.org; Wed, 20 Jan 2016 02:32:14 +0100 Original-Received: from localhost ([::1]:39819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLhd7-00043U-80 for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 20:32:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLhd3-00043M-J0 for emacs-devel@gnu.org; Tue, 19 Jan 2016 20:32:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLhcy-0006wm-J5 for emacs-devel@gnu.org; Tue, 19 Jan 2016 20:32:09 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:59494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLhcy-0006wf-Cf for emacs-devel@gnu.org; Tue, 19 Jan 2016 20:32:04 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id u0K1W0ec013641; Tue, 19 Jan 2016 20:32:01 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 2311DAE9D8; Tue, 19 Jan 2016 20:32:00 -0500 (EST) In-Reply-To: <569ED9F6.3050003@yandex.ru> (Dmitry Gutov's message of "Wed, 20 Jan 2016 03:51:02 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered TRK_NCM1=0.2, RV5555=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5555> : inlines <4200> : streams <1573722> : uri <2123364> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:198405 Archived-At: >> 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? Hmm... can't remember exactly what were the problems. I think it had to do with my desire to reproduce the exact same behavior as the old filecache.el. FWIW, see the current diff I have. > What's the main difference between the list provided by filecache.el and the > list of files used by project-find-file? Probably nothing very significant. But filecache.el uses a particular completion scheme that I wanted to try and preserve. > Too late how? In that by the time (not sure if measured in seconds or in chars) company kicks in, there's only a single completion left, and it's just a couple extra chars. > - If you have to type too many chars for completion to kick in, lower > company-minimum-prefix-length? Yes, I think that's what's going on. E.g. after typing "<", I think we can pretty much immediately pop up the completion menu. Or at most after one more char. > 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. Good, so we should be able to do it within nxml's capf. > 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.) Not sure in general (e.g. for attributes), but for tag names at least, I think that's pretty much the case. > It seems to me the functional completion tables could be complex > enough already. Not sure what you mean by "complex enough": do you mean "flexible enough that we don't need a new mechanism", or "so complex that adding yet another method would make them really unbearable"? > 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. But the only argument they receive is the completion-table, so we need them to be "dispatchable". [ Side note: I've been toying with the idea of "callable objects", by which I mean thingies which have slots and dispatchable types (like cl-structs or eieio objects) but which can also be passed to funcall. We could use them for the advice objects of nadvice.el, for the stream objects of stream.el, and potentially here as well. ] Stefan