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: Sun, 10 Mar 2019 21:15:16 -0400 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> <407232ad-b1ef-7338-5fd2-735da9721562@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="203221"; 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: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 11 02:20:54 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 1h39cb-000qlH-MI for ged-emacs-devel@m.gmane.org; Mon, 11 Mar 2019 02:20:53 +0100 Original-Received: from localhost ([127.0.0.1]:53473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h39ca-0005bG-Jt for ged-emacs-devel@m.gmane.org; Sun, 10 Mar 2019 21:20:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h39bh-0005Vm-5G for emacs-devel@gnu.org; Sun, 10 Mar 2019 21:19:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h39XG-0007wf-7m for emacs-devel@gnu.org; Sun, 10 Mar 2019 21:15:24 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:41495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h39XD-0007vH-L9 for emacs-devel@gnu.org; Sun, 10 Mar 2019 21:15:20 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x2B1FGBG004621; Sun, 10 Mar 2019 21:15:16 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 316236A541; Sun, 10 Mar 2019 21:15:16 -0400 (EDT) In-Reply-To: <407232ad-b1ef-7338-5fd2-735da9721562@yandex.ru> (Dmitry Gutov's message of "Mon, 11 Mar 2019 02:17:45 +0200") 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, RV6499=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6499> : inlines <7030> : streams <1815349> : uri <2810518> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:234044 Archived-At: >>> Also also, combining the flex sorting with most other kinds will most likely >>> make the flex sorting hard to notice. >> Depends on the ordering (see below). > With most helpful/meaningful kinds, then? With such sorting where most candidates get a different score, it's difficult to combine the sorting indeed: depending on the precedence we give to each type of score either the flex sorting will be unnoticeable or the other one will be unnoticeable. Of course, if we're careful we can try and tune the weighting of the types of scores so that both scoring have a visible impact, but I have the impression that it's going to require too careful tuning to be usable in practice. > You mean it can't be used to change settings for the "other" categories, the > defaults, right? Why don't we use the key 't' for this (with the > corresponding tiny code change somewhere else)? Ah, we could yes. That's equivalent to using another global var, indeed. Currently we use global vars (completion-styles and completion-cycle-threshold) for that purpose, mostly by accident. >> The downside of the heuristic sort of cycle-sort is that sometimes/often >> the heuristic is poor (by default it's just based on string >> length ;-( ), so the *Completions* buffer would look "unsorted". > Improving the heuristics should also help, of course. But it can be left > for later. I'm afraid that if we drop the display-sort and use cycle-sort everywhere, there's going to be a very strong reaction from users not appreciating the change. Even more so if the heuristic is poor. Stefan