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: Tue, 12 Feb 2019 22:17:56 +0000 Message-ID: <871s4czm5n.fsf@gmail.com> References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.org> <87lg2mynrg.fsf@gmail.com> 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="77084"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 12 23:18:14 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 1gtgNX-000Js3-Fj for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2019 23:18:11 +0100 Original-Received: from localhost ([127.0.0.1]:46972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtgNW-0001ny-Cz for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2019 17:18:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtgNQ-0001nj-SO for emacs-devel@gnu.org; Tue, 12 Feb 2019 17:18:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtgNP-0005rZ-PZ for emacs-devel@gnu.org; Tue, 12 Feb 2019 17:18:04 -0500 Original-Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:39829) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gtgNP-0005mk-IV for emacs-devel@gnu.org; Tue, 12 Feb 2019 17:18:03 -0500 Original-Received: by mail-wr1-x432.google.com with SMTP id t27so278745wra.6 for ; Tue, 12 Feb 2019 14:18:00 -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=S/1+uOJyM4FfKYgkjhzN+a20RGIXjUAiA9rW0U1x98A=; b=tvCz7OBMvj93uy6rporurVYnpPIqwQ3Qd/yJYOOqegeO7cZtNnOVWcj7G+ovWfmXLp 2URrJl9UNVVY4cE7UQANOzNhmc50uS64gkMC4nY15+tSBOGqmzv25lSj/q9g/uh8ehwr sCNYk25b3vQlc5z5UeseysMliFB/Ljtq7aj/oWNGpKIjNuyYWFU1UCHAhAouJdBypYSK X1IX/+txT5Nr/NBx8Liemkg7E/d9QqUVjC9gYbiD02QVkK0BnyDvnj/9hDs1V9k9ZKjM 2nE/gx9nDrGdWQJPuPeHhU9SUDkkf1sOjSgM+7/t6/pHm1Vfi6fS4bOrvypFBt9QlEF+ vkVA== 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=S/1+uOJyM4FfKYgkjhzN+a20RGIXjUAiA9rW0U1x98A=; b=e3eb97MhL8rNBYCqtajcyJOEMWslZVZZmMzND7HwGFkGbI7f331jw9MDxQofYJW4YI JtS22yNhZWNXmgBXtdDTG61s1Yy1I5zjDpYpGb2n8Ay+53LgKlc420mYCRjBfeDKngSI B9LlNJB/GDF84Rx/4+MzF9RSepeJFYDCgI/YankkENaryM0HQJDqDbJeI4/uSHpnaerm +s2L38GyI9MQj9ll8BNKZ9PDOv1x+kuZ0DcPmT1QH4gEmrymNoF0hapFyioaXVeisR7O YbLkTTrT0gUXAJE6/vkmVkJfeR0ge0oXc6By6XiAxNp9qoGKlJEU4Xi5rd+scF+tM05a 3lAA== X-Gm-Message-State: AHQUAuYGTFQ032r3wHWOVkFwjNNZ/Ef1WPW35ZHkdnUl6Zsuf3Z1QQbT nqPG/jvAVDIbkWvPOmogd3vLkUOj X-Google-Smtp-Source: AHgI3IaGDZwOjmfv9CMIy/4FoQiKu1OteZyqP07sTFlCSmX2xqHGC8KaJFX104Yu7dRc9T/wNQzhxQ== X-Received: by 2002:a5d:4945:: with SMTP id r5mr4334674wrs.295.1550009879235; Tue, 12 Feb 2019 14:17:59 -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 p68sm3143952wmp.17.2019.02.12.14.17.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Feb 2019 14:17:58 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Tue, 12 Feb 2019 09:08:03 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::432 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:233264 Archived-At: Stefan Monnier writes: > Not sure if it's related to icomplete. Maybe the length-heuristic is > just not good for buffer names. Agreed.=20 > I think this length heuristic also works reasonably well in several > other circumstances (e.g. file names). OK. Makes sense. Just to be sure we're talking about completion-all-sorted-completions, right? > It seems like it would be a clear win (the buffer-list order is a much > better heuristic than the length). I'm so glad you're volunteering to do this ;-) >>> 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 also offers a completion-table (which I use via > a completion-at-point-function). But I can use that table with another UI right? Is that completion-at-point-function in Emacs or in your config? >> 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. > > Writing the function is of course the easy part.=20 > The problem is where/how to insert this function. We have to decide on a good standard order/combination of sorting functions. If we decide that's not good enough for some cases we can go for more indirections =C3=A0 la CL method combinations. (wonder if cl-generic has method combinations). But this could very possibly be overdesigning at this point. > Duh! I meant to add some idiotic scolding about those typos but got > side tracked by the annotations issue. Sorry. I promise to be more > firm next time. Since this makes fixing my dumb mistakes more fun, I hereby scold you for your lack of scolding. >> I don't see the problem fully, > Hmm... I guess in the completion-style case, you could indeed look at > all the returned completions to compute the max-length and do some > right-alignment based on that. For some reason, I feel like it'd be > better done elsewhere, tho (e.g. maybe company would rather right-align > based on the max-length of the *displayed* completions rather than > based on the max-length of all the completions). I'll think better about this once we sort out the sorting, which has priority. >> 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? > > Fine by me. I'd call the score property `completion-score` because > I don't see any reason why it should be specific to the completion-style > (you could even have `flex` combine its score with a `completion-score` > property previously set by the completion-table, and then have the > front end combine that with its own scoring). > > I think you can also make minibuffer-completion-help sort according to > that `completion-score`. > > Regarding the code, see comments below. I've pushed a new version fixing the problems you reported off-list. I did that _before_ reading this message. I'll take a look at this new batch, do the obvious fixes. But before submitting anything sorting-related, I'd like Dmitry to show a patch for his sorting idea on top of scratch/new-flex-completion-style, try it out a bit and then report back here. Jo=C3=A3o