From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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, 24 Feb 2019 03:03:34 +0300 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="87735"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Thunderbird/66.0 To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 24 01:04:30 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 1gxhHS-000Mhh-7k for ged-emacs-devel@m.gmane.org; Sun, 24 Feb 2019 01:04:30 +0100 Original-Received: from localhost ([127.0.0.1]:44135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxhHR-000141-1L for ged-emacs-devel@m.gmane.org; Sat, 23 Feb 2019 19:04:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxhGi-00013a-OL for emacs-devel@gnu.org; Sat, 23 Feb 2019 19:03:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gxhGh-0002Dg-Jb for emacs-devel@gnu.org; Sat, 23 Feb 2019 19:03:44 -0500 Original-Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]:34153) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gxhGf-0002AD-FY for emacs-devel@gnu.org; Sat, 23 Feb 2019 19:03:43 -0500 Original-Received: by mail-lf1-x12d.google.com with SMTP id u21so4350157lfu.1 for ; Sat, 23 Feb 2019 16:03:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WpTV+hRxB5l7t+3LAm2WMclT+s2wcVzJTFezVpJZ75I=; b=tOohpGHfCY1q3Z2fp3UnW0y7IGak0ZC1OpvTPScGg6rCKyXdqpRUtpM5/pxs1VTLVI tqzeEaPZvxS2C3GITphPKEvaOAwInnLXdjH4XmmCswv0nLyPeamCk8YSpLYaH0ltY0n6 G11s6sjznagDzV8xYjJ4lEn0+Cnpzp+cIlQKlN4tN2iqOlauU1PBh9tgT5DF+i3JiDME 8o5ZTz2CVq6r1Jwb5FS106D2HPJA5mGNxURpNkIfqXwO26RYJGerwN8lVx9F5sF2y4w9 edF8s+uNn3QYX3eODtkQbe2oiOkLnN2voAfkwRVSHkmveOaCFADIYRLl4GI3XT9cPsLd irng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WpTV+hRxB5l7t+3LAm2WMclT+s2wcVzJTFezVpJZ75I=; b=oLlZr9SFSNXjYNRqFjW5RcSJ3tawmOmQlnhsVOm29paBf2PpuXfyi4CJpW7gZYLPd7 pla3ZMtr3u3E91szS6xVwtvzmVWjWINIeAgL/uiyXu6XbcisxhwyImGAlhmieqQQk12g 8v5jCsIfFWs6qm9gOKFenvSB5jxClnFKR6t0MkIyEvipoAjt8MZaPSYEb+zVue3nVij6 xwBYlc7zsS/S15ezedLE84LhuD0U74A/hAtLQd+ZkLhch4OvdBBj2u11nwRc4nWCdXNJ /1guHcvXfGujhFXCyj8Nq685hg8UoVw+HDtcMKzAxxSQD0idgv0FTsp0FBa/BUr55O2O +blA== X-Gm-Message-State: AHQUAubZvi/4fesvCpgNRJ1leCYlPt9eqWLeHZkE4fC/7iyRRBio25N1 rYG9NYNW3HuEM4nSgyTuPu2LdXoy X-Google-Smtp-Source: AHgI3IYiR1rC5RVknIyAXIaeKt2bQS1A+sAdcOr6EwJT09t6CJtAJsYKGrMftbPF6PjOUl/P3SA/sA== X-Received: by 2002:a19:f517:: with SMTP id j23mr6267716lfb.118.1550966615694; Sat, 23 Feb 2019 16:03:35 -0800 (PST) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id 2sm1568526ljh.41.2019.02.23.16.03.34 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 23 Feb 2019 16:03:34 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::12d 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:233556 Archived-At: On 19.02.2019 19:10, Stefan Monnier wrote: >>> 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. Very well. This may be off topic now, but to the best of my recollection this discussion started from the question of the ability to add flex matching to particular completion tables. So that's where I was coming from, FWIW. > But those are orthogonal: the completion style can offer one kind of > sorting and that should work for all completion tables. Orthogonal indeed, but it should be easier, implementation-wise, to only have one way that defines sorting logic. And also easier to port to the "new system", whenever that comes. Also also, combining the flex sorting with most other kinds will most likely make the flex sorting hard to notice. But please don't take this as a strong disagreement. Just an opinion. > 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". Put those defaults into completion-category-defaults, and you basically have my proposal, isn't that right? > - Let completion-category-overrides specify other choices. > > This leaves some questions unanswered, tho: > > - What about the distinction between cycle-sort and display-sort? TBH, I still don't know what's the difference between these. Meanwhile, company-capf has not support for the former, company has different kinds of paging through the popup, and it's working okay. > - 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?). Erm, I'd try the simpler approach first. If the tables A and B are supposed to be sorted differently, couldn't they return different (but similarly sounding) category names? Or if that's not generally feasible, what else would the sorting styles dispatch on? The tables themselves? > - Should we allow completion tables to offer several sorting choices? You mean different completion scores? If you just mean other kinds of orderings, I think the user will choose via completion-category-overrides. > 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. *thumbsup* > 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`). Apparently you're proposing to fix that by making the default sorting function to be flex-compatible. That sounds okay.