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: Tue, 12 Feb 2019 03:25:24 +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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="30964"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0 Cc: emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 12 01:26:20 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 1gtLtz-0007t5-KO for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2019 01:26:19 +0100 Original-Received: from localhost ([127.0.0.1]:58676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtLty-0003hw-CJ for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 19:26:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtLth-0003dx-I6 for emacs-devel@gnu.org; Mon, 11 Feb 2019 19:26:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtLtf-0005hv-58 for emacs-devel@gnu.org; Mon, 11 Feb 2019 19:26:01 -0500 Original-Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]:34000) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gtLtc-0005Et-Ib for emacs-devel@gnu.org; Mon, 11 Feb 2019 19:25:57 -0500 Original-Received: by mail-lf1-x129.google.com with SMTP id u21so619514lfu.1 for ; Mon, 11 Feb 2019 16:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WdOXRCLECUcbresKNzuiCHEgb1jmXhcXy8blGgVXPGA=; b=L6TVFkggaYlHUVG+/lTZINXLvjC4Mk/X9HKaNVk9Gp6nNYimuEq6EAGkwsk+B6qsx4 l/agTXj/DGbiphU8T6Qvr+YPjp0y6MrRl4V4NLONNm1vQyd9Xu3/P8DG9ku2Acy0hiMo y6aGnzqXKg9nQWdZf3FWrCtU/prdbhZQry4aBCm7pvlOEwYn1VY50kiiWzKC46+v0tPs HnuQrJtRMVA52vhSn00ajLYtqvJL65W3WwrZMz6oTTMV41A1ZenZEUkq6irYFZRPA7IJ OAMJoRBGeZGFcXctcO5P2Bp3Av9ouACDD/vyMSXr+IylNP2N3NiOmhJvZG23IW6QEVy6 dLqQ== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WdOXRCLECUcbresKNzuiCHEgb1jmXhcXy8blGgVXPGA=; b=clw1GiIsWRZH6WWnga6/OLDmb1Owk1T8ekRpF02ESXgNNPnC/EDTuJCP3REKwpSQiq S6LXJ5OwD+1Yp/NrBdu5caOxUru3XxX6qNUirOr87j2XlzkxIzI5mMr4+uNG4yf3xZSc PV483bVfkfrUw4B5jKJaskbtkO3TCsZG8xN/b++gQwIr4wTDgDUzV+HufI2tR+dYSv8G 2VTe4Mae8VxR4FBeRB6MQcU3NAoWgdJN53y3U+TUa65EibG5mAc4WgNoSyUog02YPw2c WK1CYDHOQjo6f3thpmaoqzIqxo+kCmAJ2gEOJl/bpmEUmUfF5ieWS2wyOu1EkJqQx3AB meRw== X-Gm-Message-State: AHQUAuaxhZV1hMs6dNDoqjymVKuAqkhRTfxP3qN8HJEx4rwa/Tz45dhr uxRWEz6B/oO8ZoJx404FoOrICVHHByg= X-Google-Smtp-Source: AHgI3IYr/SpjV5YpgzOApYgsmqH9OYFZK6iZbANdk2C2ymSVxUHPoD2bRcAXcnCMRbtGCY03V+ei3g== X-Received: by 2002:ac2:53b1:: with SMTP id j17mr500101lfh.143.1549931126076; Mon, 11 Feb 2019 16:25:26 -0800 (PST) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id d15-v6sm2401483lja.38.2019.02.11.16.25.25 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 16:25:25 -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::129 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:233241 Archived-At: On 06.02.2019 22:47, João Távora wrote: > Perhaps I'm missing something, and that is taiting all the remaining > discussion. Aren't these properties/metadata thingies specific to the > completion table (files, buffers, code completions, etc)? metadata - yes, properties - no (those are extra elements at the end of the list returned by completion-at-point-functions). See completion--metadata and completion-extra-properties. display-sort-function, for now, can only be a metadata element (though that shouldn't be hard to change). annotation-function, however, can be either. So as things stand, the use of this completion style that'd see in mind, is when a particular completion function returns a table that indicates a particular category (for which the use of flex completion style is enabled), and a particular display-sort-function in its metadata. Consequently, a preexisting completion tables wouldn't be supported. But like I said, it shouldn't be hard to change either. > In otherwords I should be able to mix and match > > - frontends > - completion styles > - backends > > Right? Well all I'm saying is that, when using the flex/scatter > completion style, it's almost always, if not always always, a better > idea to stable-sort by flex-match score. I dunno, sorting takes CPU time anyways. Not sure a combination of several sorting functions will frequently give a better result than just one of them. > One good way to see this is to try my code with your company.el package, > which doesn't (hopefully _doesn't yet_) use the completion style's > sorting hints. You can try it in Emacs Lisp. First do: > > (setq completion-styles '(flex)) > > Now go into the *scratch* buffer and type "undo". You'll see it's not > very useful: the first match you get is ":argument-precedence-order", a > legitimate match, for sure, but you probably meant something related to > the undo facilities. And you have to scroll quite a bit before you to > "buffer-undo-list", which is buried deep in the many many b's that > match. But then, if you enable company-sort-by-occurrence via company-transformers, the completion style's sorting won't be visible anymore anyway. It's a question whether any other sorting approaches end up being helpful, but maybe some hybrid functions will work, where both occurrences and flex score are taken into account. > Eventually, we can add a keybinding to resort exclusively according to > the table or exclusively according to the completion style. In the approach I'm thinking of, both options are the same sorting function. > And we want "barfoo" to come first. string-distance talks about > "deletions, insertions and substitutions required to transform a string > into another". Perhaps if it measured also "move operations" it would > be a better measure. That's helpful to consider for the actual scores, and sorting. > Then instead of the percentage, we could show just the number of 1-char > editing operations, including moves, to turn the pattern into the > candidate. That's a measure with actual meaning. And still, seeing it wouldn't help me if I'm just writing code. Sorry for being blunt. Sort by them, sure. But show the values to the user? Why? >> Even if they do, there's no need to couple this annotation addition to >> the completion style. Just use a new annotation function that looks up >> the text properties that the style adds, and adds them on. > > Again, this would only affect the specific completion table that I'm > writing this function for, right? Or can I write metadata functions for > completion styles? The former, more or less. This creates a certain limitation, sure, but it shouldn't be a problem for Eglot.