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: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness Date: Wed, 13 Feb 2019 11:00:58 -0500 Message-ID: References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.org> <556bfb2e-4720-c86a-c964-f057b50041b6@yandex.ru> <87va1xw7ms.fsf@gmail.com> <212f7cc9-c0c6-bcf8-f200-ea74db261dc3@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="230612"; 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 Wed Feb 13 17:35:50 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 1gtxVl-000xn8-11 for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2019 17:35:49 +0100 Original-Received: from localhost ([127.0.0.1]:59749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtxVk-0007r4-0F for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2019 11:35:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtwyG-0006WB-N0 for emacs-devel@gnu.org; Wed, 13 Feb 2019 11:01:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtwyE-0007vG-PS for emacs-devel@gnu.org; Wed, 13 Feb 2019 11:01:12 -0500 Original-Received: from [195.159.176.226] (port=35244 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtwyE-0007u9-I1 for emacs-devel@gnu.org; Wed, 13 Feb 2019 11:01:10 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gtwyB-000IUT-Tn for emacs-devel@gnu.org; Wed, 13 Feb 2019 17:01:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:H+33bS6iHCfQxGjIYzeh38u1Q0s= 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:233281 Archived-At: > On the one hand, yes, but it's the abstraction we already have, and it will > allow flex to work properly at least with certain completion tables. Which > is a win. The problem I see with it is that performing the style-sorting via completion-metadata or via completion-extra-properties is a hack that works by breaking abstractions. So, not only it will only work with some completion tables, but for that you'll need to introduce "wrong" code in those completion tables. I'd rather we extend the infrastructure so that completion styles can do their own sorting. > On the other hand, a search for display-sort-function through Emacs's > sources seems to indicate that the design is kind of a failure: there are > only a couple places that set it to something, and in both cases it's > #'identity, meaning "do not re-sort". Indeed. Those cases *do* perform sorting, but they sort directly inside their `all-completions` function rather than in their display-sort-function. So yes, the design is kind of a failure, tho the alternative of having a boolean in the metadata to say "don't sort" is no simpler. > So minibuffer.el might want to take a cue from Company and > company-transformers, to make this universal, we could add sorting as > a feature of completion styles, or as a separate user option, for maximum > flexibility. The question is really: how/where would a completion style specify which sorting it wants to do (based on the above-mentioned past experience, we can assume that they'll want to do their sorting directly in completion-all-completions and then specify "don't sort any further"), and then how to change minibuffer.el to do that. Currently, completion-all-completions does not return any information about which style was used, so either we change this API so that it also returns which style was used, or some info about the style gets added as text-properties to influence subsequent sorting, or completion-all-completions is changed to perform the sorting (which may require extending its calling convention so the caller can tell it which kind of sorting it wants). > Now, I wouldn't say it's terrible that sort-by-occurrence-and-score would > know specifically about flex (I don't think there's going to be a lot of > different styles in this flavor), but sure, like you proposed in another > email, the property can have a neutral name like completion-score. Using scores would make it possible to combine different scoring systems by weighting the different parts. I'm not completely happy with the use of text-properties, tho (e.g. ideally completion-all-completion could return a list of pairs of the form (CANDIDATE . SCORE)). But it has the very significant advantage of requiring much fewer changes. Stefan