From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: project--completing-read-strict breaks ada-mode project completion table Date: Wed, 20 Feb 2019 21:00:43 -0500 Message-ID: References: <20180922154639.23195.66360@vcs0.savannah.gnu.org> <20180922154640.9D58220310@vcs0.savannah.gnu.org> <54108dbc-9d12-06ff-3f1d-151118e9b234@yandex.ru> <4e729d1e-bb31-455f-fd44-e99ae5a6b9fa@yandex.ru> <86zhs5r9lr.fsf_-_@stephe-leake.org> <08de4d90-d678-0524-9356-f9a3515bf0c4@yandex.ru> <86a7k2rabi.fsf@stephe-leake.org> <86sgxso27d.fsf@stephe-leake.org> <69076784-83cb-5cc7-be39-fea990b8535e@yandex.ru> <861s55n6wk.fsf@stephe-leake.org> <86lg2swg14.fsf@stephe-leake.org> <86wom5vlki.fsf@stephe-leake.org> <86sgwi1bb1.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="158604"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 21 03:01:57 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwdgT-000f5X-0w for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2019 03:01:57 +0100 Original-Received: from localhost ([127.0.0.1]:53016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gwdgS-0008Tl-3Z for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2019 21:01:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gwdfc-0008TS-IQ for emacs-devel@gnu.org; Wed, 20 Feb 2019 21:01:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gwdfa-00062D-Vy for emacs-devel@gnu.org; Wed, 20 Feb 2019 21:01:04 -0500 Original-Received: from [195.159.176.226] (port=52818 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gwdfa-0005s7-Ms for emacs-devel@gnu.org; Wed, 20 Feb 2019 21:01:02 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gwdfP-000dbJ-MB for emacs-devel@gnu.org; Thu, 21 Feb 2019 03:00:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:P9DP+7ZEQjuImFyuCR0zo9L5J2Q= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:233502 Archived-At: >> We definitely want to support the case where the collection works OK for >> most/many/some styles, where it also wants to provide its own style, and >> where we want the user to be able to override that (via >> completion-category-oiverrides). So even for those collections where >> only its own style works, it makes sense to use that same (overridable) >> mechanism rather than provide another. > > But then project backends that choose to provide a uniquify-file (or any > other "broken") completion table won't "just work"; the user will have > to set completion-category-default or -overrides to get completion to > work (as illustrated by locate-uniquified-file; more below). No, indeed we don't want that: we want that the completion-table-provided style is used by default without the user having to take any special steps. But we also want it to be possible for the user to specify some other style to use instead. >>>> I don't understand this. Why can't the completion style compute the >>>> common-prefix? >>> The root is _not_ the common prefix of the current matches; >> >> I don't mean "of the current matches" but "of the entire collection". >> (try-completion "" collection) should return just that, so the >> completion-style does have access to it (unless the collection doesn't >> implement `try-completion` correctly for that case, but it seems that >> in the present situation we have control over the collection so we can >> make sure it works correctly). > Yes, that would work, and be horribly inefficient. Indeed, it would only work acceptably if either the backend special cases the "" case or the style is able to do enough caching. >> What I meant is that when we call uniq-file-get-data-string we already >> know that the user string is a valid match, so there shouldn't be any >> need to search in the completion table. E.g. if it's >> "foo-file1.text" we should be able to just prepend the >> hidden common prefix to the output of uniq-file-to-table-input, no? > Yes, but that common prefix is only stored implicitly in the table. > If we had a completion object, we could store it there. Ah, OK, so it's an artifact of limitations of the current API, makes sense. > I guess by "mixing with other styles" you mean processing a list of > styles; if we had (basic uniquify-files), for on an empty string > 'basic' would present a list of absolute file names, but for after > a string that matches some basename 'uniquify-files' would present > uniquified file names. That would be confusing, and I now realize that's > why I only specify one completion style. Exactly: they're mutually incompatible (not necessary in the sense that something will break, but in the sense that the result makes no sense for the user). > It will probably require editing minibuffer.el, but I'll think about it. Right, I'm thinking from the point of view that minibuffer.el can be changed at will. If/when we figure out a clean solution there, we can maybe think about how to try and make it work with current minibuffer.el. > Note that uniq-file-completion-table is an optimization; the > uniquify-file completion style does work with a list of absolute files, > or any completion table function that returns such a list. Indeed, thinking about the kind of manipulation done for your uniquification, it seems like it pretty much requires to have the complete list from the start (and to basically start by rewriting this list from the data format to the user format on entry, then do normal completion on this and then convert the final result back to data format). Stefan