From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: new-flex-completion-style Date: Mon, 11 Feb 2019 22:16:19 +0000 Message-ID: <87lg2mynrg.fsf@gmail.com> References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="33740"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 23:18:24 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 1gtJuC-0008d7-HX for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 23:18:24 +0100 Original-Received: from localhost ([127.0.0.1]:57129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtJuB-0006Ef-94 for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 17:18:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtJsq-0006Cv-KJ for emacs-devel@gnu.org; Mon, 11 Feb 2019 17:17:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtJsp-0003Mj-2N for emacs-devel@gnu.org; Mon, 11 Feb 2019 17:17:00 -0500 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:36870) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gtJsm-0003Cg-Ld for emacs-devel@gnu.org; Mon, 11 Feb 2019 17:16:57 -0500 Original-Received: by mail-wr1-x435.google.com with SMTP id c8so533800wrs.4 for ; Mon, 11 Feb 2019 14:16:22 -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=cX0Apd/oxj+3QweTM4lpR8VMtsyrtH99mgBEM3hapAc=; b=Bjas16EMc5IcJ7H/ZgZMJ9sY6/cbYBnDvdn2oCt/153yx0wUwdAK628+kgAPfgI8HY qFyhg7KFilcfohhSbrLzKaVO8JOXtl4s+xAv1e9Xmr6uk5fGS0PCtRixgcEtOlazyrD5 XBEcPJ2TKufrNzIU/sjUhTdm1LwU93S1zUqD4Q7fKOUls3rByWwHdnSlUq6okKmbUccw j2+m5ssCw9FTshRugwm4++0wkBOIeE5f7PZIVgx3Q5rqCOmyorUj7VVWUbFD+G4O1AQC UZ16SPsR6jV2Iq5av2Kv8wOGfu6cCTrByZrUfp6Nqdmek2jAF1YJe6ah1+eyp7hHPmvU IVvg== 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=cX0Apd/oxj+3QweTM4lpR8VMtsyrtH99mgBEM3hapAc=; b=fF54PzQU5NQujfaf480nPgU9UFdF9Df0tl0daa8v+MbroFlMQ1IgCepgWx9ZNO6LYb n3sRX5VoTmStA8+d3EVFoHs+t1FJXlI3SjsSwdE9fwJ0a3CvmyZ2zc49GPHUjJqETjCH uGKSP+WwLdYYiO10IvOxjuVHud1pBhzfjzcNlfik+juBcswbTDTD/YfbPqgmBg2w3TcC /QiuT+jky2bHyYpgH39OdRr9nwVmi5vEyb0vRNhUPSIEueSMBdZLmgAqVSfR4LTHD5pS swDtKPqv4K6fsUFRtueoHDCgNtLFPVer8fF7oJCqFtIsuugdZRyHqjuNRSOoC/lA3kKd gXkw== X-Gm-Message-State: AHQUAub/GcdvRPYkB4JSLP5QMD5ts9f2Wsqnk3z/eFvfz+t14pVlkRJH NrniPL5+RrJ9zLUTkRYn4XU= X-Google-Smtp-Source: AHgI3Ibt04cDYSGzWpfkbjlQMKWAj218c4kSTeKRYq1TkDnCOnBAL604+23yokSQhfhh631xMpL+8A== X-Received: by 2002:a5d:4ac2:: with SMTP id y2mr314196wrs.98.1549923381654; Mon, 11 Feb 2019 14:16:21 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id y18sm584852wmi.5.2019.02.11.14.16.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Feb 2019 14:16:21 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Mon, 11 Feb 2019 16:10:38 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::435 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:233232 Archived-At: Stefan Monnier writes: > W.r.t the UI sorting minibuffer.el has 2 different UIs with 2 different > sorting behaviors: there's the *Completions* buffer where results are > sorted alphabetically, and there's the force-complete cycling which > sorts by most-recently seen (using the minibuffer history variable) and > by length. Tangent: When using icomplete (who else here uses icomplete?), this is (the length) not good at all for switching buffers. I want it to behave like ido, where the natural order of buffer-list is preserved when the buffer can't be found in the minibuffer-history-variable. IOW for the icomplete UI, sorting by length makes little sense. It may make sense for completion-at-point cycling. I'm working on a patch for this. > All this was designed in the context of completion tables and styles > where all returned candidates are basically equally likely. > > Flex is going in the direction of completion systems where instead of > splitting the candidates between "possible matches" and "impossible > matches", the matches are all considered as possible, with some more > likely than others. > So in such a context, it's of utmost importance for the completion > table-or-style to provide its own sorting. And in that case, I guess > most UIs should simply follow that sorting (instead of the current > situation where each UI uses its own sorting). The only problem is that completion-style doesn't have a point to plug-in sorting yet. So I thought good place to start is to place hints in the completion-candidates. > Still, in a case such as lisp/ecomplete.el where the completion table > provides its own sorting based on recent-usage-frequency, how should > this sorting be combined with that of flex? I can see arguments in > favor of saying that the flex-weight should be ignored in favor of the > usage-frequency. ecomplete has its own UI in ecomplete-display-matches? It's a question of using or discarding the completion-style sorting hints stored in each candidate. My view of the matter is: completion table provides its sorting which _can_ be overriden by completion style's sorting which _can_ be overriden by completion UI's sorting. AFAIU this can be done by writing comparison functions that return nil if the current sorting should be agnostic to both elements. >> Up until now, there was no way for completion styles to control >> sorting. This change add such a facility and activated it for the n= ew >> "flex" completion style. > > I'd like to move towards a completion-style API that uses cl-generic. > E.g. introduce generic functions like `completion-style-try-completion` > which would be like `completion-try-completion` but takes an additional > `style` argument and dispatches based on it (replacing the dispatch > based on completion-style-alist). This is a good change, but it's not absolutely necessary to what I am proposing right now. >> * lisp/minibuffer.el (minibuffer-completion-help): Use >> completion-style-sort-order and compeltion-style-annotation > ^^^^^^^^^^ > completion >> properties. >> (completion-pcm--hilit-commonality): Propertize completion with >> 'completion-pcm-commonality-score. >> (completion-flx-all-completions): Porpertize completion with > ^^^^^^^^^^ > Propertize Thanks. >> completion-style-sort-order and completion-style-annotation. > Regarding annotations, I think being able to `concat` at the end is > too limited. If you take your example from sly, we'd like the "15%" > annotations to be right-aligned and I don't see an easy way to do that > with the facility you introduce. I don't see the problem fully, but probably I'd rather remove the annotation completely for now, until we have a better of how where we want to place it. As Dmitry suggested, the flex score annotation is mostly a gimmick, we shouldn't add it until we have a good idea of how it should work. > > The current annotation facility is also too limited in another way: in > read-char-by-name we annotate each char name with the actual char it > names, but we'd really like to prepend this annotation rather than > append it (it would make the chars much easier to see and to compare), > but the current annotation system doesn't offer this flexibility. > > So I'd encourage you to come up with a more flexible annotation system > that allows prepending annotations as well as right-alignment (and > ideally combinations of those, with several columns, ...). What do you suggest? I'd prefer small things that can be added incrementally. IOW, I don't have time for grand designs right now, I'm mostly scratching the personal itch that is making icomplete.el not make me miss ido.el so much. So to summarize, I propose to add (1) the fafa9ec commit introducing flex completion and (2) a new commit extracted from 2c7577558 which adds the flex scoring calculation to each match, but doesn't do anything with it yet. Deal? The first commit by itself can already greatly improve icomplete Ui. And the second commit should encourage UI devs to start taking the completion-style-sort-order hint into account. If Dmitry does that in company-capf, we get decent flex completion for little cost. Jo=C3=A3o