From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: new-flex-completion-style Date: Wed, 13 Feb 2019 13:54:27 -0500 Message-ID: References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.org> <87lg2mynrg.fsf@gmail.com> <871s4czm5n.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="80822"; 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: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 13 19:55:30 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 1gtzgv-000Kiq-BV for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2019 19:55:29 +0100 Original-Received: from localhost ([127.0.0.1]:33720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtzgu-0004i8-9O for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2019 13:55:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtzg8-00048B-RM for emacs-devel@gnu.org; Wed, 13 Feb 2019 13:54:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtzg6-0004jf-7z for emacs-devel@gnu.org; Wed, 13 Feb 2019 13:54:39 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:45920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtzg5-0004S1-LU for emacs-devel@gnu.org; Wed, 13 Feb 2019 13:54:37 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1DIsRnq016040; Wed, 13 Feb 2019 13:54:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 203D06A325; Wed, 13 Feb 2019 13:54:27 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1v?= =?windows-1252?Q?ora=22's?= message of "Wed, 13 Feb 2019 17:29:30 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6482=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6482> : inlines <7017> : streams <1812941> : uri <2795780> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:233289 Archived-At: > I've removed this for now, I.e. there's absolutely no sorting yet before > we agree on who should be doing it and where. But why would the empty > string be there anyway? Don't know: you'd have to ask it. > I don't "understand" it either :-) My question wasn't to justify the idea behind the algorithm but just to describe in words what the code is supposedly computing. I.e. something like what you wrote here: > The formula assigns higher scores to "better" matches. It's bound by > [0..1] and in the form of a quotient. For the numerator, it counts the > +++. For the denominator, it takes counts the number of --- in each > such group, exponentiates that number to a "falloff constant", adds it > to the total, adds one to the final sum, and then multiples by the > length of the string. Making sure I understand: - "counts the +++" will always return the length of the pattern, right? So this is used just to normalize the result to ]0..1]. - if the falloff constant is 0, the denominator is the number of places where a "star" had to be added (plus one). And if the falloff constant is positive it prefers more insertions of shorter text chunks over fewer insertions of longer text chunks, and if it's negative it oddly prefers longer insertions over shorter ones. > Anyway, what do you think? Is this acceptable or so you have anything > better? Fine by me (tho maybe I wouldn't count the final "---", to more closely match [no pun intended] the usual prefix completion). FWIW, in my "forgive" completion style I used the equivalent of a falloff constant of 0 (i.e. I didn't care about the length of the "---" but only about their number). > OK, I'll call it "last-b". It'll be eternally indebted to you. >>> + (funcall update-score 0 start) >>> (while md >>> - (put-text-property start (pop md) >>> + (funcall update-score start (car md)) >>> + (put-text-property start >>> + (pop md) >> >> The extra line-break after `start` seems spurious. > Were you expecting it to have very deep, hidden meaning? But OK. I was actually bothered by the fact that the `diff` indicates a change on an expression that's actually not modified (other than by insertion of a line-break). Anal retentiveness for ever! >>> + (put-text-property >>> + 0 1 'completion-pcm-commonality-score >>> + (/ score-numerator (* len (1+ score-denominator)) 1.0) str)) >> >> This will signal an error when `str` is the empty string :-( > > Ooops, but that that happen? Can an empty string be pcm-matched > by some pattern? There's I think it can if the pattern is empty. So maybe all those put/get-text-property are fine if you make sure this code is never even called when the pattern is empty. BTW, the patch below seems to improve the behavior (e.g. it lets `.../emacs/cfi TAB` complete to `.../emacs/config` as it should since all remaining matches also match "config"). Stefan diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 8ea70b14f1..f5171bb2d0 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3434,22 +3434,7 @@ completion-flex-try-completion #'completion-flex--make-flex-pattern))) (if minibuffer-completing-file-name (setq all (completion-pcm--filename-try-filter all))) - (cond ((not (consp all)) - all) - ((not (consp (cdr all))) ; single completion - (if (equal string (car all)) - t - (cons (car all) (length (car all))))) - (t - ;; If more than one completion, try some "merging". - ;; Meaning add as much as possible to the user's - ;; pattern without losing any possible matches in - ;; `all'. If that fails, leave user input - ;; untouched. - (let ((probe (completion-pcm--merge-try pattern all prefix suffix))) - (if (stringp probe) - (cons probe (length probe)) - (cons string point))))))) + (completion-pcm--merge-try pattern all prefix suffix))) (defun completion-flex-all-completions (string table pred point) "Get flex-completions of STRING in TABLE, given PRED and POINT."