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: Wed, 13 Feb 2019 02:47:30 +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="17293"; 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 Wed Feb 13 01:11:50 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 1gti9W-0004Oy-DV for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2019 01:11:50 +0100 Original-Received: from localhost ([127.0.0.1]:48267 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gti9V-0005kX-86 for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2019 19:11:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gti5q-0002bl-Pj for emacs-devel@gnu.org; Tue, 12 Feb 2019 19:08:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gthm3-0002DI-Bv for emacs-devel@gnu.org; Tue, 12 Feb 2019 18:47:36 -0500 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:37440) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gthm2-00028O-UI for emacs-devel@gnu.org; Tue, 12 Feb 2019 18:47:35 -0500 Original-Received: by mail-lj1-x22b.google.com with SMTP id r10-v6so403426ljj.4 for ; Tue, 12 Feb 2019 15:47:34 -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=Xf3l2ent/7Bang/V/1l6A4VlPdD8Sl4IvNSnai2WXno=; b=BYa5KMFpR1YSzzsHW/YS2ZzmZfLWsDx395bdmAgOx/Pa8oP6rUeMDXsrneV5uWC13K O5GEQN9Ukcohtd3Vrt1a+/Tnp9NGmxnBQeo7vrpKRpaywOw1lQi56ryNfq9J3TrHr4VQ vEBNZ3QhlwRd1h9BWsc4YPls09vewyT8NL+8ick8558RrbkxFd4OzYkNJkdcCbMLwp8C ngMTZ0ALn0enAkG++oawU9LAGoZK4atqNC/lWM9hR0X0Vb6hc9blDkSRmz3BT6U2hJuZ aCUEWfP1YdSEILrR/5XknxNIJjAjazGazAIaWlTqZwyCNZgHPGR/8zVCnO0Gy6zu25YN 9VCw== 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=Xf3l2ent/7Bang/V/1l6A4VlPdD8Sl4IvNSnai2WXno=; b=AkXNcmpgsL9JbHEiGp5Klj7fvs1A7sfhTgWJvz9GDYYpkNqVUL5jRqHUqqYoxmLPjq /JOn8N7fURjUbR+PuSW5snuwo7ZJkdfJWNCIOMU9UtMeWSBzVQo7XeBxIRRmZ/JgJrgo ddCRT1nPU9aHb6c6WcV99oEax4lkuG7rY6MSURKx1Fx67mwGND1MXOljdjGrrP0HH8K8 0CvA9hLdKL2+l2MHQIgkAs0llNtBHrhKpv1IF0MSNTjKTo0RcelMmpseEq4GaHc1kq/q djVoSpani4owsESEHfwkzPHZppVg76XNcYhm4mA+ibJ33FCufTAuFHLMH2ASRAFuS6+j d96w== X-Gm-Message-State: AHQUAuZZcagNT09EavlhbwLSaaJX2+UTH1SbWB+vFgqSjTQ2iAJvrI3r ZCjYL+zl11fg0YpPzV12GyHM+A0n X-Google-Smtp-Source: AHgI3IaJaW+dRyiTdaTi1vnl40yjodbtCMlNeMFKU9OcvVNHEfoWqGhr7DhH1irx3OuCU2M1KCkJnA== X-Received: by 2002:a2e:3219:: with SMTP id y25-v6mr3917791ljy.20.1550015252718; Tue, 12 Feb 2019 15:47:32 -0800 (PST) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id h3sm3316363lfj.25.2019.02.12.15.47.31 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 15:47:31 -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::22b 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:233266 Archived-At: On 12.02.2019 20:21, João Távora wrote: > Oh. That's what I feared (I think) It would be nice to add something > seemingly orthogonal like a "completion style" to all completion UI's > and all tables, without needing to change the completion tables > (granted, it would be good to *also* not change the UI's, but I'm not > sure there a solution for that). You have a point, sure. But I'd rather reuse the abstraction we already have as the first step, and then maybe extend it (or add a new one), rather add sorting code that uses these text properties to an existing function. > I dunno what you dunno. When using flex/scatter it's *really* important > to sort by flex-match. I suggested "stable sorting" because it's a > slightly more decent thing to completion tables. And by sorting twice > it's not like we're changing the Big-O complexity or anything. Constants matter sometimes, too. Not necessarily in this case, but... > But I also don't mind a scheme where the style's sorting completely > takes over (and we save those CPU cycles). That would be ideal, I think. > I don't know what company-transformers are. Not too hard to find out, I think. > On the one hand I suppose > when you want to sort by occurance, you ... want to sort by occurrence. > So if you use the symbol "foofooubarbarnbazbazdquuxquuxo" very often > you'll see it sort to the top for your "undo" example. So maybe company > should take the style's sorting last here, dunno. OK, I was probably wrong here. Like, if only some of the completions have occurences, the rest would be sorted by flex scores, and that... sounds pretty good. > In this case I would first sort by occurance and then style-score. > There's no easy way to make a hybrid function, so we must pick a > default. For all the examples I've been given, it seems that > flex-sorting should always come last. Since flex is the first and only > style that carries some sorting idea with it, perhaps it's not a very > bad idea to give it _some_ priority by default. You probably mean assign the least priority to flex's scores. The flex score sort would happen first with this approach, though. Almost all completions will have different scores, so sorting by them last would make all the previous sorting disappear. >>> 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. > > How would you synthetize it? Err, not the way you'd want. The table would just be designed to be used with the completion style. And so its sorting function. > In the general case, so the user has an idea _why_ something is being > automatically. Humans generally gain confidence in algorithms if > they're shown human-comprehensible hints as to why it is is doing > something (humans generally also like this from other humans, which > explains why you ask me so many questions :-). For a little while, maybe. To obtain the said confidence. And then, I'd opt to turn it off, because I prefer to avoid too much visual clutter (one of the reasons to use Emacs). > In this particular case, it's a very common idiom when displaying > tables/lists of something. Perhaps in the "occurance sorting" field, > he/she will choose another word used less frequently for stylistic > purposes. > > But, all that said, I'm not going to kill myself over the annotation, > nor do I think it even merits a customization option, though it's > probably not hard to do it anyway. You see, regarding the annotations as well, it makes more sense to reuse the existing mechanism, or make it more flexible as well, somehow. >> The former, more or less. This creates a certain limitation, sure, but >> it shouldn't be a problem for Eglot. > > Hmm? By far, Eglot isn't the only one thing I'm interested in enhancing > (actually, I've had few opportunities to actualy _use_ Eglot lately). Sly's completion table could take the same approach. As long as the completion table is under your control, it's all good. By the way, we could also add an indirection for display-sort-function (and maybe the -cycle- one as well) similar to the styles. So we not only assign a style (or several of them) based on the category, but also the sorting function. This way, sorting of buffers the right way would still work and make sense. And at the same time, the user could change certain categories to use both flex matching and flex score sorting. That's more work for the user, but still. Seems kinda elegant.