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: Tue, 19 Feb 2019 11:10:24 -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> <2733dee8-f5a6-396f-228a-84f225d43a1c@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="154159"; 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 Tue Feb 19 17:11:59 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 1gw7zy-000dzh-Qb for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2019 17:11:58 +0100 Original-Received: from localhost ([127.0.0.1]:51136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gw7zx-0005Lq-N3 for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2019 11:11:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gw7yr-0005KQ-LB for emacs-devel@gnu.org; Tue, 19 Feb 2019 11:10:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gw7yg-0001RN-9W for emacs-devel@gnu.org; Tue, 19 Feb 2019 11:10:44 -0500 Original-Received: from [195.159.176.226] (port=37726 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gw7yf-0001PN-HM for emacs-devel@gnu.org; Tue, 19 Feb 2019 11:10:37 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gw7yb-000cNr-Cq for emacs-devel@gnu.org; Tue, 19 Feb 2019 17:10:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:tNrKK+xJvQucp4EDV19wo27gWMs= 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:233456 Archived-At: >> 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. > Since we seem to want to redo completion tables in a major way anyway, That's no guarantee that it will happen soon or at all, and it will have to provide some backward compatibility. And the more hacks we see using the current system, the more difficult backward compatibility may become. > I wouldn't worry about that too much, as long as the result is functional. It'd be OK if it's indispensable, but I think there are better alternatives that are easy to install right away. >> I'd rather we extend the infrastructure so that completion styles can do >> their own sorting. > That's one option. Another option, which I've mentioned before, is to create > an indirection for sorting functions via the completion table's > category. Similar to the one that completions styles have. But those are orthogonal: the completion style can offer one kind of sorting and that should work for all completion tables. Completion tables can also offer their own kind of sorting (and it should work with all completion styles). How 'bout: - Add global sorting config var(s?), to choose which kind of sorting to use, which would default to sorting based on "scores first and alphabetical after that". - Let completion-category-overrides specify other choices. This leaves some questions unanswered, tho: - What about the distinction between cycle-sort and display-sort? - Should the new var and new entries in completion-category-overrides contain directly sorting functions, or should they contain just the name of "sorting styles" with a separate table mapping those styles to actual functions (e.g. because a given style like `date` might be implemented differently for different completion tables?). - Should we allow completion tables to offer several sorting choices? In any case, in the mean time we can probably just introduce the new sorting based on "scores first and alphabetical after that" and use it by default. > The category-based approach should circumvent that problem. > With this approach, completion styles don't indicate sorting, and whatever > entity did set up the completion style to be used (the user, a configuration > package, etc) would need to set up both completion styles and sorting > functions to match. I think it'd be annoying for users to have to not only add `flex` to their completion-styles but also change some sorting option at the same time before that completion style becomes usable (in most cases, the current alphabetical sorting works really poorly for `flex`). > I think text properties are fine here. It has its downsides, but I agree it seems like the better choice. Stefan