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: new-flex-completion-style (was: [Emacs-diffs] scratch/ 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness) Date: Mon, 11 Feb 2019 16:10:38 -0500 Message-ID: References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.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="11381"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 22:11:05 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 1gtIr2-0002pX-To for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 22:11:05 +0100 Original-Received: from localhost ([127.0.0.1]:56339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtIr1-0005D6-QL for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 16:11:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtIqv-0005Cy-Od for emacs-devel@gnu.org; Mon, 11 Feb 2019 16:10:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtIqt-00015N-Rg for emacs-devel@gnu.org; Mon, 11 Feb 2019 16:10:57 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:44448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtIqr-0000y7-T3 for emacs-devel@gnu.org; Mon, 11 Feb 2019 16:10:55 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1BLAc3d005103; Mon, 11 Feb 2019 16:10:38 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 49FD2AE145; Mon, 11 Feb 2019 16:10:38 -0500 (EST) In-Reply-To: <20190202232828.4AE452159A@vcs0.savannah.gnu.org> (=?windows-1252?Q?=22Jo=E3o=09T=E1vora=22's?= message of "Sat, 2 Feb 2019 18:28:28 -0500 (EST)") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 3 Rules triggered LNG_SB_1=0.2, EDT_SA_DN_PASS=0, RV6480=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6480> : inlines <7015> : streams <1812759> : uri <2794774> 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.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:233227 Archived-At: > Score, sort and annotate flex-style completions according to match > tightness Sorting is a complicated matter here: we have completion tables, completion styles, and completion front-ends, and all three seem to want to be able to sort. Obviously, the front-end has ultimate control, so we can't stop it from sorting the way it likes, but we'd like it to be able to make an informed choice. As for sorting by the completion table or sorting by the completion style, it's hard to figure out what should be done in general. FWIW, it seems that all the completion tables that care about sorting do it by sorting directly in `all-completions` and then setting the *-sort-function to `identity`. Presumably this can only DTRT for "flat" completion tables. W.r.t the UI sorting minibuffer.el has 2 different UIs with 2 different sorting behaviors: there's the *Completions* buffer where results are sorted alphabetically, and there's the force-complete cycling which sorts by most-recently seen (using the minibuffer history variable) and by length. All this was designed in the context of completion tables and styles where all returned candidates are basically equally likely. Flex is going in the direction of completion systems where instead of splitting the candidates between "possible matches" and "impossible matches", the matches are all considered as possible, with some more likely than others. So in such a context, it's of utmost importance for the completion table-or-style to provide its own sorting. And in that case, I guess most UIs should simply follow that sorting (instead of the current situation where each UI uses its own sorting). Still, in a case such as lisp/ecomplete.el where the completion table provides its own sorting based on recent-usage-frequency, how should this sorting be combined with that of flex? I can see arguments in favor of saying that the flex-weight should be ignored in favor of the usage-frequency. > Up until now, there was no way for completion styles to control > sorting. This change add such a facility and activated it for the new > "flex" completion style. I'd like to move towards a completion-style API that uses cl-generic. E.g. introduce generic functions like `completion-style-try-completion` which would be like `completion-try-completion` but takes an additional `style` argument and dispatches based on it (replacing the dispatch based on completion-style-alist). Maybe the sorting code (currently in minibuffer-completion-help) should be moved to such a generic function, so the completion style would have the choice of how it uses the `display-sort-function`. But then should we do the same with the sorting done in `completion-all-sorted-completions` or should we come up with a single generic function that covers both needs? > * lisp/minibuffer.el (minibuffer-completion-help): Use > completion-style-sort-order and compeltion-style-annotation ^^^^^^^^^^ completion > properties. > (completion-pcm--hilit-commonality): Propertize completion with > 'completion-pcm-commonality-score. > (completion-flx-all-completions): Porpertize completion with ^^^^^^^^^^ Propertize > completion-style-sort-order and completion-style-annotation. Regarding annotations, I think being able to `concat` at the end is too limited. If you take your example from sly, we'd like the "15%" annotations to be right-aligned and I don't see an easy way to do that with the facility you introduce. The current annotation facility is also too limited in another way: in read-char-by-name we annotate each char name with the actual char it names, but we'd really like to prepend this annotation rather than append it (it would make the chars much easier to see and to compare), but the current annotation system doesn't offer this flexibility. So I'd encourage you to come up with a more flexible annotation system that allows prepending annotations as well as right-alignment (and ideally combinations of those, with several columns, ...). Stefan