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: Mon, 11 Mar 2019 02:17:45 +0200 Message-ID: <407232ad-b1ef-7338-5fd2-735da9721562@yandex.ru> 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="205653"; 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 Mon Mar 11 01:18:34 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 1h38eH-000rOp-NT for ged-emacs-devel@m.gmane.org; Mon, 11 Mar 2019 01:18:33 +0100 Original-Received: from localhost ([127.0.0.1]:52875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h38eG-0004Y7-Oi for ged-emacs-devel@m.gmane.org; Sun, 10 Mar 2019 20:18:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h38dc-0004Xz-BA for emacs-devel@gnu.org; Sun, 10 Mar 2019 20:17:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h38db-0001tQ-9O for emacs-devel@gnu.org; Sun, 10 Mar 2019 20:17:52 -0400 Original-Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:40923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h38da-0001sE-VF for emacs-devel@gnu.org; Sun, 10 Mar 2019 20:17:51 -0400 Original-Received: by mail-lf1-x12c.google.com with SMTP id u68so2073358lff.7 for ; Sun, 10 Mar 2019 17:17:50 -0700 (PDT) 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=TKvagcH9f9vpsCoVnBRj0aAxzIlkYTZYkY37z+TpuYI=; b=cVPkx40NadSNoDnpkHGLw2vw37yzDo7zato90wSqIfDYdOtX8LOyDRhHI5e23BmvFF C99uCrrWLykuUCEXkC9CnM2EPK79W/3ogToOpDHUtqAE9+babTZUQ6Aem6JMhYARCBug nqYsAq6IvbAgfse39+H2bOW6UGzEXDH1A8TSV9OsX/cr2Ey0P+0+cv6Q2jb+bBhg6feA MJCNCX1vWN2zBp3XJ2zrJX3mNoq3AiseR/G6FKDnQAOLFB6S5zTeeNvH+UL9oL3P7VYk pIZ6yLmAWFL8xVHrkhz+cv5u8RvbO4tSoMF9jprh1Ma60S/qy50gELltnIIRjzY3ULFH Gy3w== 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=TKvagcH9f9vpsCoVnBRj0aAxzIlkYTZYkY37z+TpuYI=; b=IeKUCYet16Z5Y4qObvgL3zKKHZRrfKAnTaNlVxq+NrggNYm43U0EcZYgSTlz6Dq2bi NPiwlavBLo4ytsKp32g5pP+WBzBAP1nsJHA6/Y/TYFDDHXhEoAvXwEUpSR+y3AUwD/Dv 7sC3bgkXPXUO7Ay3svfZrykzuJSj08AeQBZEcIO0hiW0Y5sdtur2aFW6uSrYgyAE+Ihw skzpOoxTpIkr4T7ChhliiTv2gbrmTJ+vEbjxp3yc0/V/4PEnE9i8jRwqtMLmKWOeNSPX PAMP8fUGgvJifPlRqschXDGbPnFhhpXitBILkTuBKHdkzXKtLrLvCQIrrdVrMqbn8pyh gxOA== X-Gm-Message-State: APjAAAU6j3A1oOw7RgOZb+nZ6qyff+njrd9yiPWGSAYiaP3UzneoTDPq SbsUh7wUNOAvRMBsymNHG1xGAUtQ X-Google-Smtp-Source: APXvYqxQLiTPpkuAASYeFWupyDb/FpJZPbC4ysv9uPb2agZShqbE9XHrRPXqpUpFPnQWc0qIuRzr5A== X-Received: by 2002:ac2:4343:: with SMTP id o3mr14283620lfl.129.1552263468788; Sun, 10 Mar 2019 17:17:48 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id v1sm736698ljc.57.2019.03.10.17.17.46 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 10 Mar 2019 17:17:47 -0700 (PDT) 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::12c 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:234043 Archived-At: On 27.02.2019 19:12, Stefan Monnier wrote: > I see. I was taking the point of view of a generic `flex` method for > use anywhere you like (I think the original motivation was to use it in > conjunction with `icomplete-mode` to more closely match to `ido` > behavior). That's a worthy goal as well, of course. Not sure it will be ideal for e.g. eglot's completion table, but that's a separate discussion, I guess. >> 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? >>> - 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? > > completion-category-defaults is an alist providing extra settings for > specific categories, so it's not "global" in the sense I meant above > because can't be used to choose the sorting used for categories not > mentioned in completion-category-defaults. 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)? I think this will fit the name of the variable, as well as the way it is used. The function completion--category-override could use a rename in this case, though. This will also let us set the completion style defaults for the "other" categories (and the user too, if completion-category-overrides supports the same). > display-sort is the sorting used when displaying the candidates in > a list like *Completions* whereas cycle-sort is the sorting used when > your TAB cycles through possible candidates (and it's also used in > icomplete-mode). I see, thanks. > In display-sort we currently sort alphabetically whereas in cycle-sort > we want to use a heuristic that puts more likely choices first. > > Maybe we should drop this distinction and just use the same sorting > everywhere (which would have to be the cycle-sort by default I think, > because the alphabetical sort is really a poor choice when cycling in > my experience). Yeah, I do believe we'd prefer the most likely choices at the top in the display-sort case as well (or for company-capf, at least). > 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.