From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: new-flex-completion-style Date: Thu, 14 Feb 2019 22:32:28 -0800 (PST) Message-ID: <5ccdc392-23da-4aa6-8648-cf55fe056e34@default> References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <871s4czm5n.fsf@gmail.com> <1f4513ab-cd39-4543-9b1a-743e1307dd54@default> <23b6cda2-0f37-4c41-b664-5353505c0cd1@default> <35dac269-3666-45cb-b6ea-09cf5864841a@default> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="54137"; mail-complaints-to="usenet@blaine.gmane.org" To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 15 07:46:04 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 1guXG8-000DxD-2S for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 07:46:04 +0100 Original-Received: from localhost ([127.0.0.1]:33382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guXG7-00082N-2u for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 01:46:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guXEs-0007hW-LV for emacs-devel@gnu.org; Fri, 15 Feb 2019 01:44:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guX35-0005Pl-8q for emacs-devel@gnu.org; Fri, 15 Feb 2019 01:32:36 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:40582) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guX34-0005Mi-2o for emacs-devel@gnu.org; Fri, 15 Feb 2019 01:32:34 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1F6Sp3I132055; Fri, 15 Feb 2019 06:32:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=f8O37O2lfkDmMOhUTDr18saaDNPZf6IGrLoFQfPRGZI=; b=iGKvYOFm6q9mwwbSssGZsV8LFL5OIiXUBBC2VTYHL9eh4it1Sy+y8yNfW8hgfFHWjbVD FFWm8MyW5nhf7JrCSKgO7sVDK9Dui22ZQf/CgyUGHxP1Ps+SD5zRA95jqpQm4maWeKuP 7ERVTpSD0ZJ+Yw4CG/aAyYEdy6tfsTddhpJipKeZEbgY92y4l0D8pgpv5q5gUB2gN1dp nhA8PQMZExL38fDyEmhAZUlLBME8KouMudYAZZE1G20go5ZhRHFL682oAE70kG3Tbjdr /uXYQVjrN929QjFRFy3mWljEL7xs2Kmuzj+2yYreN5UenXsMQuT3IDZx5cSNkkx0p3P2 Ng== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2qhrekv0nw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 06:32:30 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1F6WTqc015284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 06:32:30 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x1F6WTUe016430; Fri, 15 Feb 2019 06:32:29 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4810.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9167 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902150047 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.86 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:233354 Archived-At: > >> I guess one could consider `flx` scoring as just another kind of > >> sorting, but I'm pretty sure that it can give odd results when used > >> with (say) regexp-style completion. > > Depends on the regexp. But sure, you wouldn't > > want to sort based on scoring that privileges > > substring match length for input that is a wild regexp. >=20 > My point is that flx scoring is usually based on the idea that the > candidate does match using flx matching, whereas that might not be the > case i[f] the matching was done some other way. So the scoring result ca= n > be completely meaningless (or it could even signal an error). >=20 > IOW matching and scoring can be intimately linked because the scoring is > based on *how* the candidate matched the input. Yes. And regexp matching is an outlier. My point about regexp matching was that for completion many actual uses of regexp matching are substring matches or close to it. (`foobar' is a regexp.) And besides this being the case for perhaps most regexp-input matches (for completion), most other match methods involve input chars that are also in the candidates, so flx scoring even with non-flx matching is generally not outlandish. I think flx-score sorting is probably more useful when you've typed relatively little and there are many matches. In a way it privileges, by sorting (and hence for access by, e.g., cycling), candidates that might match in two different ways, the optional one being flx. And yes, again, flx scoring is no doubt more useful with some match methods than with others. Finally, I can't tell you how useful it might really be. YMMV. I can say that it's another sort order. ;-) FWIW, the predicate I actually use for sorting by `flx-score' just does alphabetical comparison if the input doesn't return a `flx-score' for each of the two candidates (i.e., if at least one does not flx-match your input). (defun icicle-flx-score-greater-p (s1 s2) "Non-nil means the `flx-score' of S1 is greater than that of S2. That is, the cars of the `flx-score' values are compared. If `flx-score' returns nil for either argument, then they are compared using `icicle-case-string-less-p'. This function requires library `flx.el'." (let* ((input (if (and (icicle-file-name-input-p) insert-default-directory) (file-name-nondirectory icicle-current-input) icicle-current-input)) (score1 (flx-score s1 input)) (score2 (flx-score s2 input))) (if (and score1 score2) (> (car score1) (car score2)) (icicle-case-string-less-p s1 s2))))