From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= 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: Wed, 06 Feb 2019 19:47:13 +0000 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="38168"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 06 20:50: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 1grTCv-0009hN-8T for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 20:50:05 +0100 Original-Received: from localhost ([127.0.0.1]:57674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grTCu-00059l-AA for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 14:50:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grTAN-0003zM-Q6 for emacs-devel@gnu.org; Wed, 06 Feb 2019 14:47:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1grTAL-0004Tq-St for emacs-devel@gnu.org; Wed, 06 Feb 2019 14:47:27 -0500 Original-Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:51047) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1grTAJ-0004SR-GX for emacs-devel@gnu.org; Wed, 06 Feb 2019 14:47:25 -0500 Original-Received: by mail-wm1-x32d.google.com with SMTP id z5so3766343wmf.0 for ; Wed, 06 Feb 2019 11:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=6Ag2ZOyZqdqQWQgwinm4xYKzNz8WsTwiHRqiC7NaSRs=; b=MAneveMcqJKMHpwhoW6sJ1bcTMk7xVWC93Vplvh1bWoN3HSw/FgBrVVOG2PJhzko31 33WRHunbKRYC6joG7nU0BHzpI0fm3MxKChOGz5OnmKXAraSHiargRlFkmz+/igk1K4UJ txn6nx6ugufVfyCaJk7Vh1WKwhLCRAMBx3E/aUy1pHhiEiX1/Ixe2kmV9SWKkQePclAk pXxfyndpEYbWft8g110H8Qpd/Wz1en2SBtrVkW7VQr09E+JObNOKbRL/NjoFDHJZ1nU1 uNFK5kTJbqMrQ9oauvDyA8Zqr/6gRvwX3wbuTKIvq5trRsn+oSSy686Tw4Tk9JHt46sC UGGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6Ag2ZOyZqdqQWQgwinm4xYKzNz8WsTwiHRqiC7NaSRs=; b=EM3OORPpPVHRMY49/HrMrtd0foxg3tWo2R+jsoJx+7eTpxoIkmPeJ1Y8SnkhKNM3eQ b/YzaSU7ZEP5RVAXMPhRVCFKhThXWTvQQtiOYtPXQP8hleIkcdMnf+7TMq0V41oaAZ8H it4qVx247KqCqIBs+VWN2SHTI9JWpER53VEaJG42LtMSuYWqhTbENjOd+EHvxbW2i7eF KaWFXx9ypA3kMds6hT0GmGZh7uUeMStU/WF+GlMySv0xkRYPVUZIA7Um4Bybgz/52kYC HPPvBiWMLF9e94h4m6TY7hSdRwX+rfvqy+Hf9kNyMB1KZveNvllHmGjAa3038X2dUsSm aAdg== X-Gm-Message-State: AHQUAuaX+YlDFpu56teALpO2/2S+FRatpEm3I54a6xdB5j+SRjyHbpbu 5d39lHJiPX/fQicKqpOip+Xsc9by X-Google-Smtp-Source: AHgI3IYAccZ8Vxyo8SXZNZ5uoRsBLOzAUuBdw7+yWesM0tLE9yT5Q7lPbKLNNM0FjnSAJcxbx750Ww== X-Received: by 2002:a1c:7dd6:: with SMTP id y205mr4142470wmc.121.1549482437273; Wed, 06 Feb 2019 11:47:17 -0800 (PST) Original-Received: from GONDOMAR.yourcompany.com (mail1.siscog.pt. [89.115.233.242]) by smtp.gmail.com with ESMTPSA id l20sm43113424wrb.93.2019.02.06.11.47.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Feb 2019 11:47:16 -0800 (PST) In-Reply-To: <212f7cc9-c0c6-bcf8-f200-ea74db261dc3@yandex.ru> (Dmitry Gutov's message of "Wed, 6 Feb 2019 21:54:45 +0300") X-Antivirus: AVG (VPS 190205-6, 05-02-2019), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32d 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:233062 Archived-At: Dmitry Gutov writes: > On 06.02.2019 13:09, Jo=E3o T=E1vora wrote: > >> Perhaps. But it only does so when the completion style explicitly >> wanted it. And even so, the sort order should be stable, i.e. if the >> completion style puts numerically equal values in two completions, they >> should retain the backend's order. And, obviously, it it doesn't put >> any values in that property, then the backend's order is also retained. > > To put it simply, we already have a way to indicate the completions > sorting: provide a particular property, or metadata. 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)? > I'd prefer not to couple completion style with sorting, because > someone somewhere might prefer to go without it (and use some other > sorting options, e.g. by frequency of use or mentions in the buffer). > >> In my experience, at least for the "flex" (also called "scatter", by the >> way) completion style, the frontend's sorting takes precedence > > Not sure what you mean by frontend here. I meant the completion style. Though technically the completion style is a degree short of a frontend, because it is a way to select the completions collected by the backend (the completion table in Emacs parlance) and pass them to the graphical frontend, be it icomplete's, the *Completions* buffer or company. 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. 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. >> It is already customizable: you don't have to use "flex" completion >> style. Let's first try it out and then see if we need _more_ >> customization. > > I'd rather we start with the "more simply" alternative I've > mentioned. But others are welcome to add their opinions. Eventually, we can add a keybinding to resort exclusively according to the table or exclusively according to the completion style. >>> Is this for debugging? >> >> At the moment, yes mostly. But it could not be. In SLY, I give users >> an indication of how the scoring algorithm is working. See it in >> action: >> >> https://raw.githubusercontent.com/joaotavora/sly/master/doc/animations/c= ompany-flex-completion.gif > > It's kind of neat, but to be honest I don't see how these percentages > help a random user. I can agree they should be improved. It would be good to integrate some prior art regarding flex string matching that has a good measure of the match quality. The one in the prototype is a empirical thing that works quite OK for Common Lisp and myself. `string-distance', for instance, gives the the Levenshtein distance. It's got a fancy name, but it's not very useful for flex completion before (string-distance "foo" "barfoo") =3D (string-distance "foo" "frodos") 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. 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. > 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? Jo=E3o