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: Fri, 15 Feb 2019 00:54:43 +0000 (UTC) Message-ID: <35dac269-3666-45cb-b6ea-09cf5864841a@default> References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.org> <87lg2mynrg.fsf@gmail.com> <871s4czm5n.fsf@gmail.com> <1f4513ab-cd39-4543-9b1a-743e1307dd54@default> <23b6cda2-0f37-4c41-b664-5353505c0cd1@default> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="265862"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Daniel Pittman , =?iso-8859-1?B?Sm/jbyBU4XZvcmE=?= , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 15 01:56:25 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 1guRnl-00173n-Il for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 01:56:25 +0100 Original-Received: from localhost ([127.0.0.1]:57495 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guRnk-0000Yj-J2 for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2019 19:56:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guRmN-0000Wi-CF for emacs-devel@gnu.org; Thu, 14 Feb 2019 19:55:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guRmL-0007i7-Gy for emacs-devel@gnu.org; Thu, 14 Feb 2019 19:54:59 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:36710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guRmJ-0007Wv-Ly for emacs-devel@gnu.org; Thu, 14 Feb 2019 19:54:57 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1F0n6aN097518; Fri, 15 Feb 2019 00:54:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=SFrxpEI1lbObaTxVnqtsptnyXYioAgfVGcgj+DG0Ab8=; b=FXOY9qTaKdXIYQbsYyPuqDB95UBwe+fmdamjFkpwlwF/wnUlbHqWQn8Gz0gJIYK7KxaS bteP6N/OxWTcbCM2czf2mzvkGpu6jqgBZHqUTGunSJBDN1v4Zl3Wpyqj+4Eh74prZX+1 TAVp9/QP1gO1Bq31h9dPhvdvBmWwjruPcQ2Gcj53FNOl2WuQxxqaB7xmL0qWdFZE9ctG MLyRxNlo5uoiVBbcFPq7e0vLqq9K9wyDt3rE61xpVNgbpBu0q0m1ofQB5CMzS0IpOCdV /VEBV0Px+V0vtWqun/2VjRwWUEcLbluTFRQ1PUFykHEpEkOAp+WVIJySQRBVcrybTWHb ZA== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2qhre5u2u4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 00:54:52 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1F0slJ0015645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 00:54:47 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1F0siBp010485; Fri, 15 Feb 2019 00:54:44 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=921 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902150004 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.79 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:233350 Archived-At: > >> > Can you see that some of the following predefined orders > >> > might be advantageous in particular contexts/use cases? > >> > Can you see that whether matching is scatter, regexp, > >> > basic prefix, or others, any of the following can be > >> > useful? > >> No, I can't. > > Seriously? >=20 > All the examples you give are non-specific to the completion-style used, > whereas the `flx` scoring seems more directly related to the > completion style. The sort order that a user might want in any given context can depend on any number of things. Some completion styles might be context-related (i.e., more suited to some kinds of completion, e.g. file names, than to other kinds). But for the most part they are not. Categories bring us closer to use contexts/cases than styles, I guess. But actually, I did mention two fuzzy-matching methods that impose the sort order used - they give you no other sort choice. In particular, they can't give you a sort order that is especially useful for a certain context. I don't see scatter-matching as limiting in that way. You can use it with the sort orders I listed. That's not the case for `fuzzy-match.el' matching or Swank fuzzy symbol matching. > 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. FWIW, Icicles uses `flx' _only_ for sorting (by `flx-score'), not for matching. And yes, it's just another sorting method. I could have included it in the list I showed. And yes, it's not context-specific (though it's likely more useful with some contexts than with others). > So maybe, another way to look at it is that there are several sorting > choices, one of them being provided by the completion-style. That goes back to my point about coupling such things together (matching and sorting) versus decoupling and so letting a user mix & match (modulo the rare exception). If a user specifies a particular sort order in a completion style then s?he can't also use the rest of that style without that sort order, or vice versa - not without defining additional completion styles that provide those other possibilities. Sure, allowing a style to include a sort can be handy if you want to use that combination a lot. It can also be limiting. Why didn't you just include categories, not as separately specifiable, but only as part of styles? Surely you saw an advantage in being able to mix & match. Same thing applies to sorting, in general (i.e. modulo some exceptions, as mentioned). Being able to include a sort order in a style is one thing. Having to do that, to be able to choose a sort order, is another thing.